Container supply chain security in GCP - Commands & Configuration

Introduction

Container supply chain security helps protect your container images from being tampered with or infected by malware before they run. It ensures that only trusted and verified images are used in your cloud environment.

When you want to make sure the container images you deploy are safe and have not been altered by attackers.

When you need to verify the origin and integrity of container images before running them in production.

When you want to automatically scan container images for vulnerabilities before deployment.

When you want to enforce policies that only allow signed and trusted images to run in your Kubernetes clusters.

When you want to track and audit the history of container images used in your cloud projects.

Config File - cloudbuild.yaml

cloudbuild.yaml

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['container', 'images', 'add-tag', 'gcr.io/my-project/my-app@sha256:abcdef1234567890', 'gcr.io/my-project/my-app:latest']
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['container', 'images', 'sign', 'gcr.io/my-project/my-app:latest']
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['container', 'images', 'describe', 'gcr.io/my-project/my-app:latest']
options:
  logging: CLOUD_LOGGING_ONLY

This Cloud Build configuration file automates tagging, signing, and describing a container image.

steps: Defines the sequence of commands to run.

1. add-tag adds a tag to the image by its digest.

2. sign digitally signs the image to verify its authenticity.

3. describe shows details about the signed image.

options.logging ensures logs go to Cloud Logging for audit and review.

Commands

This command tags a specific container image digest with the 'latest' tag so it can be referenced easily.

Terminal

gcloud container images add-tag gcr.io/my-project/my-app@sha256:abcdef1234567890 gcr.io/my-project/my-app:latest

Expected Output

Tagging gcr.io/my-project/my-app@sha256:abcdef1234567890 as gcr.io/my-project/my-app:latest

This command digitally signs the container image to prove it comes from a trusted source and has not been changed.

Terminal

gcloud container images sign gcr.io/my-project/my-app:latest

Expected Output

Image gcr.io/my-project/my-app:latest signed successfully.

This command shows details about the container image, including its signature status and metadata.

Terminal

gcloud container images describe gcr.io/my-project/my-app:latest

Expected Output

name: gcr.io/my-project/my-app:latest

signatures:

- keyid: abcdef1234567890

  signed: true

  timestamp: '2024-06-01T12:00:00Z'

Key Concept

If you remember nothing else from this pattern, remember: signing container images ensures only trusted images run in your cloud environment.

Common Mistakes

Not signing the container image before deployment

Unsigned images can be tampered with or replaced by malicious versions without detection.

Always sign your container images after building and before deploying them.

Using image tags without referencing the image digest

Tags like 'latest' can change and may point to different images over time, causing unpredictability.

Use the image digest (sha256) to reference exact image versions when tagging and signing.

Skipping image vulnerability scanning

Unsigned images may still contain vulnerabilities that can be exploited in production.

Integrate vulnerability scanning tools in your build pipeline to check images before signing.

Summary

Tag a container image by its digest to create a stable reference.

Sign the container image to verify its authenticity and integrity.

Describe the image to confirm it is signed and trusted before deployment.

Practice

1. What is the main purpose of container supply chain security in Google Cloud?

easy

A. To automatically deploy containers to Kubernetes

B. To speed up container image downloads

C. To reduce the size of container images

D. To check every step from code to container for vulnerabilities

Solution

1. Step 1: Understand container supply chain security

   It focuses on protecting the app by verifying each step from code creation to container deployment.

2. Step 2: Identify the main goal

   The goal is to prevent vulnerabilities or bad code from reaching users by checking the entire build and deployment process.

3. Final Answer:

   To check every step from code to container for vulnerabilities -> Option D

4. Quick Check:

   Container supply chain security = check all steps [OK]

Hint: Focus on security checks from code to container [OK]

Common Mistakes:

• Thinking it only speeds up downloads
• Confusing with image size optimization
• Assuming it automatically deploys containers

2. Which Google Cloud service is primarily used to build, scan, and sign container images automatically?

easy

A. Cloud Build

B. Cloud Storage

C. Cloud Functions

D. Cloud Run

Solution

1. Step 1: Identify service for building and scanning containers

   Cloud Build is designed to automate building, scanning, and signing container images.

2. Step 2: Exclude other services

   Cloud Storage stores data, Cloud Functions run code, Cloud Run deploys containers but does not build or scan images.

3. Final Answer:

   Cloud Build -> Option A

4. Quick Check:

   Build and scan containers = Cloud Build [OK]

Hint: Remember: Build and scan = Cloud Build [OK]

Common Mistakes:

• Confusing Cloud Storage with build service
• Thinking Cloud Run builds images
• Assuming Cloud Functions handles container images

3. Given this Cloud Build YAML snippet, what will happen when the build runs?

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-app', '.']
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['container', 'images', 'scan', 'gcr.io/my-project/my-app']
images:
- 'gcr.io/my-project/my-app'

medium

A. Only builds the Docker image without scanning

B. Builds the Docker image and scans it for vulnerabilities

C. Scans the image before building it

D. Fails because scanning is not supported in Cloud Build

Solution

1. Step 1: Analyze the build steps

   The first step builds the Docker image tagged 'gcr.io/my-project/my-app'. The second step runs a scan on that image.

2. Step 2: Confirm scanning support

   Cloud Build supports scanning container images after building them using gcloud commands.

3. Final Answer:

   Builds the Docker image and scans it for vulnerabilities -> Option B

4. Quick Check:

   Build then scan = Builds the Docker image and scans it for vulnerabilities [OK]

Hint: Build first, then scan image in Cloud Build [OK]

Common Mistakes:

• Thinking scan happens before build
• Assuming scanning is unsupported
• Ignoring the order of steps

4. You wrote a Cloud Build config to scan container images, but the scan step fails with permission denied. What is the most likely fix?

medium

A. Change the image tag to a public registry

B. Increase the build timeout value

C. Grant Cloud Build service account the Container Analysis Viewer role

D. Remove the scan step from the build

Solution

1. Step 1: Identify cause of permission denied error

   Scanning container images requires permissions to access Container Analysis API data.

2. Step 2: Assign correct IAM role

   Granting the Cloud Build service account the Container Analysis Viewer role allows scanning without permission errors.

3. Final Answer:

   Grant Cloud Build service account the Container Analysis Viewer role -> Option C

4. Quick Check:

   Permission denied fix = assign Container Analysis Viewer role [OK]

Hint: Assign Container Analysis Viewer role to Cloud Build account [OK]

Common Mistakes:

• Increasing timeout does not fix permissions
• Changing image tag won't fix permission errors
• Removing scan step avoids problem but loses security

5. You want to ensure only signed container images are deployed to your GKE cluster. Which combination of GCP features should you use to enforce this?

hard

A. Binary Authorization with Cloud Build signing images

B. Cloud Run with automatic image scanning

C. Cloud Storage to store images and IAM policies

D. Cloud Functions to trigger deployment after scanning

Solution

1. Step 1: Understand requirement for signed images enforcement

   Binary Authorization lets you enforce policies that only allow signed images to deploy to GKE.

2. Step 2: Use Cloud Build to sign images

   Cloud Build can build and sign container images automatically, integrating with Binary Authorization.

3. Step 3: Exclude other options

   Cloud Run and Cloud Functions do not enforce signed image deployment. Cloud Storage is for storage, not enforcement.

4. Final Answer:

   Binary Authorization with Cloud Build signing images -> Option A

5. Quick Check:

   Signed image enforcement = Binary Authorization + Cloud Build [OK]

Hint: Use Binary Authorization plus signed images from Cloud Build [OK]

Common Mistakes:

• Confusing Cloud Run with enforcement tool
• Using Cloud Storage for enforcement
• Thinking Cloud Functions handle image signing