Container supply chain security in GCP - Step-by-Step Execution

Process Flow - Container supply chain security

Start: Developer writes code

↓

Build container image

↓

Scan image for vulnerabilities

↓

Sign image to prove authenticity

↓

Push image to secure registry

↓

Deploy container from registry

↓

Runtime security monitoring

↓

End

This flow shows how container images are created, scanned, signed, stored, deployed, and monitored to keep the supply chain secure.

Execution Sample

GCP

gcloud builds submit --tag gcr.io/my-project/my-app:v1
container analysis scan gcr.io/my-project/my-app:v1
cosign sign gcr.io/my-project/my-app:v1
kubectl apply -f deployment.yaml

This sequence builds a container image, scans it for vulnerabilities, signs it, and deploys it to Kubernetes.

Process Table

Step	Action	Tool/Command	Result	Next Step
1	Build container image	gcloud builds submit --tag gcr.io/my-project/my-app:v1	Image built and pushed to registry	Scan image
2	Scan image for vulnerabilities	gcloud container images describe gcr.io/my-project/my-app:v1 --show-package-vulnerability	No critical vulnerabilities found	Sign image
3	Sign image	cosign sign gcr.io/my-project/my-app:v1	Image signed successfully	Deploy container
4	Deploy container	kubectl apply -f deployment.yaml	Container deployed to cluster	Monitor runtime
5	Runtime security monitoring	Security tools running	No runtime threats detected	End

💡 All steps completed successfully, container supply chain secured.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Container Image	None	Built and pushed	Scanned clean	Signed	Deployed	Running securely
Vulnerabilities	Unknown	Unknown	None critical	None critical	None detected	None detected
Signature Status	Unsigned	Unsigned	Unsigned	Signed	Signed	Signed
Deployment Status	Not deployed	Not deployed	Not deployed	Not deployed	Deployed	Deployed

Key Moments - 3 Insights

Why do we scan the container image after building it?

Scanning checks for security issues before deployment, as shown in step 2 of the execution_table where vulnerabilities are checked.

What does signing the image achieve?

Signing proves the image is authentic and untampered, as seen in step 3 where the image is signed successfully.

Why is runtime monitoring important after deployment?

Because threats can appear during operation, runtime monitoring (step 5) helps detect and respond to them.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result after step 2 (Scan image)?

A Image signed successfully

B No critical vulnerabilities found

C Container deployed to cluster

D Image built and pushed to registry

💡 Hint

Check the 'Result' column for step 2 in the execution_table.

At which step is the container image signed?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' column to find when signing happens.

If a vulnerability was found during scanning, which step would change?

A Step 2: Scan image for vulnerabilities

B Step 4: Deploy container

C Step 1: Build container image

D Step 5: Runtime security monitoring

💡 Hint

Vulnerabilities are detected during scanning, see step 2 in execution_table.

Concept Snapshot

Container supply chain security ensures safe software delivery.
Steps: Build image -> Scan for vulnerabilities -> Sign image -> Push to registry -> Deploy -> Monitor runtime.
Scan early to catch issues.
Sign to prove authenticity.
Monitor to detect threats during operation.

Full Transcript

Container supply chain security involves several steps to keep software safe. First, developers build a container image and push it to a registry. Next, the image is scanned for vulnerabilities to catch any security problems early. After scanning, the image is signed to prove it is authentic and has not been tampered with. Then, the signed image is deployed to a Kubernetes cluster. Finally, runtime security monitoring watches the running containers to detect any threats. This process helps ensure that only safe and trusted containers run in production.

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