Securing the Supply Chain: Enforcing Trust from Artifact Registry to GKE with Binary Authorisation

Published on Feb 03, 2026•11 min read
Read on MediumSponsor on GitHubBuy me a Coffee
Securing the Supply Chain: Enforcing Trust from Artifact Registry to GKE with Binary Authorisation

Introduction: The "Untrusted Code" Problem

In the world of Kubernetes, kubectl apply -f deployment.yaml is a powerful command. Too powerful.

By default, a GKE cluster will happily try to run any container image you tell it to, from any registry, regardless of its origin or vulnerability status. This is a massive security gap. In a modern DevSecOps environment, we need a way to cryptographically prove: "This container was built by our trusted CI/CD pipeline, passed all security scans, and hasn't been tampered with."

The solution is Google Cloud Binary Authorisation.

Binary Authorisation is a deploy-time security control that acts as a gatekeeper for GKE. It ensures that only images with a valid, verifiable "signature" (attestation) from a trusted authority are allowed to run.

In this article, we will build a secure supply chain where Cloud Build signs an image, and GKE rejects any attempt to deploy it without that signature.

The Architecture: The Trust Pipeline

We are building a chain of trust. The developer pushes code, Cloud Build builds the container, signs it using a private key from Cloud KMS, and stores the signature. When GKE tries to pull the image, it verifies that signature using the corresponding public key.

Figure 1: The Trust Architecture. This diagram visualises how the static trust components (Keys, Notes) interact with the active deployment pipeline.
Figure 1: The Trust Architecture. This diagram visualises how the static trust components (Keys, Notes) interact with the active deployment pipeline.

Core Components Explained

  1. Cloud Key Management Service (KMS): Stores the cryptographic keys used for signing. We use an asymmetric key pair (private key to sign, public key to verify).
  2. Attestor: A Google Cloud resource that represents a trusted identity. It links a specific KMS key to a "Note" in Container Analysis.
  3. Cloud Build: Our CI/CD platform. It will build the image and act as the "signer," creating an attestation.
  4. Binary Authorisation Policy: The rule set on the GKE cluster that enforces signature verification.

Implementation Guide: Step-by-Step

Let's define our variables. We have one project: my-secure-project.

Prerequisites: API Enablement

Before starting, ensure the necessary Google Cloud APIs are enabled for your project:

bash
123456
gcloud services enable \
container.googleapis.com \
cloudbuild.googleapis.com \
binaryauthorization.googleapis.com \
containeranalysis.googleapis.com \
cloudkms.googleapis.com

Phase 1: Establishing Trust (Keys & Attestors)

Step 1: Create the Asymmetric Key Pair in KMS This key is the root of our trust. The private key will be used by Cloud Build to sign images.

bash
123456789
# Create a KeyRing
gcloud kms keyrings create binauthz-ring --location global
 
# Create an Asymmetric Signing Key
gcloud kms keys create build-signer-key \
--keyring binauthz-ring \
--location global \
--purpose asymmetric-signing \
--default-algorithm rsa-sign-pkcs1-4096-sha512

Step 2: Create the Container Analysis Note A "Note" is a piece of metadata that will be attached to container images. Think of it as a blank label waiting to be stamped.

bash
12345
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
--data '{"name": "projects/my-secure-project/notes/build-provenance-note", "attestation": {"hint": {"human_readable_name": "CI/CD Build Pipeline"}}}' \
"https://containeranalysis.googleapis.com/v1/projects/my-secure-project/notes?noteId=build-provenance-note"

Step 3: Create the Attestor Now we link the Note to our KMS key. This creates the "Attestor" entity that GKE will trust.

bash
1234567891011
gcloud container binauthz attestors create build-attestor \
--attestation-authority-note=build-provenance-note \
--attestation-authority-note-project=my-secure-project
 
# Link the KMS public key to the attestor
gcloud container binauthz attestors public-keys add \
--attestor=build-attestor \
--keyversion=1 \
--keyname=build-signer-key \
--keyring=binauthz-ring \
--location=global

Phase 2: The Build & Sign Process

We need to configure Cloud Build to sign images after building them.

Step 1: Grant Permissions to Cloud Build The Cloud Build service account needs permission to view the Note, use the KMS private key, and create attestations.

bash
123456789101112131415
PROJECT_NUMBER=$(gcloud projects describe my-secure-project --format='value(projectNumber)')
CB_SA="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
 
# Allow viewing the Note
gcloud projects add-iam-policy-binding my-secure-project \
--member="serviceAccount:${CB_SA}" --role="roles/containeranalysis.notes.viewer"
 
# Allow attaching occurrences to the Note
gcloud projects add-iam-policy-binding my-secure-project \
--member="serviceAccount:${CB_SA}" --role="roles/containeranalysis.notes.attacher"
 
# Allow using the KMS key for signing
gcloud kms keys add-iam-policy-binding build-signer-key \
--keyring binauthz-ring --location global \
--member="serviceAccount:${CB_SA}" --role="roles/cloudkms.signerVerifier"

Step 2: The cloudbuild.yaml pipeline This is a standard build, followed by a dedicated "sign" step using Google's binauthz-attestation builder.

yaml
123456789101112131415161718192021222324252627282930
steps:
# 1. Build and push the container image
- name: "gcr.io/cloud-builders/docker"
entrypoint: "bash"
args:
- "-c"
- |
docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA .
docker push us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA
# Save the digest to a file for the signing step
docker inspect --format='{{range .RepoDigests}}{{println .}}{{end}}' us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app:$COMMIT_SHA | grep "us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-app" > /workspace/image-digest.txt
 
# 2. Sign the specific digest
- name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
entrypoint: "bash"
args:
- "-c"
- |
# Read the exact digest we just pushed
DIGEST=$(cat /workspace/image-digest.txt)
 
gcloud container binauthz attestations sign-and-create \
--artifact-url="$DIGEST" \
--attestor="build-attestor" \
--attestor-project="$PROJECT_ID" \
--keyversion-project="$PROJECT_ID" \
--keyversion-location="global" \
--keyversion-keyring="binauthz-ring" \
--keyversion-key="build-signer-key" \
--keyversion="1"

Phase 3: Enforcing the Policy on GKE

Step 1: Enable Binary Authorisation on the Cluster If creating a new cluster, add --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE. For an existing cluster:

bash
123
gcloud container clusters update my-cluster \
--region=us-central1 \
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

Step 2: Configure the Policy Binary Authorisation policies are cluster-scoped. We will configure a rule for my-cluster that enforces our attestation.

(Save this as policy.yaml)

yaml
1234567891011121314151617181920212223242526
name: projects/my-secure-project/policy
globalPolicyEvaluationMode: ENABLE
 
# Default rule: Block everything that isn't whitelisted or attested
defaultAdmissionRule:
evaluationMode: ALWAYS_DENY
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
 
# Whitelists: Allow system images and specific 3rd party tools
admissionWhitelistPatterns:
- namePattern: quay.io/example-monitor/*
# --- ADDED: Google System Images (Required for GKE Stability) ---
- namePattern: gcr.io/google_containers/*
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/*
- namePattern: gke.gcr.io/*
- namePattern: gcr.io/stackdriver-agents/*
 
# Cluster-specific rule: Enforce attestation for your specific cluster
clusterAdmissionRules:
# Remember to change 'us-central1.my-cluster' to your specific region/zone and cluster name
us-central1.my-cluster:
evaluationMode: REQUIRE_ATTESTATION
enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
requireAttestationsBy:
- projects/my-secure-project/attestors/build-attestor

Note: We set defaultAdmissionRule to ALWAYS_DENY to ensure a secure-by-default posture. Crucially, we have populated admissionWhitelistPatterns with standard Google registries (such as gke.gcr.io and k8s.gcr.io). This ensures that essential system workloads (like kube-dns) are not accidentally blocked by our strict policy, while still enforcing signature verification on all applications deployed to my-cluster.

Apply the policy:

bash
gcloud container binauthz policy import policy.yaml

Final Verification

  1. Test Deny: Try to deploy an unsigned image (e.g., nginx:latest) to the cluster. GKE will reject it with an error mentioning Binary Authorisation.
  2. Test Allow: Run the Cloud Build pipeline to create and sign your image. Then, deploy that specific signed image digest to the cluster. GKE will verify the signature and allow the deployment.

Emergency Protocols: Breaking Glass

In a critical incident (e.g., Cloud Build is down, but you must deploy a hotfix), you can bypass Binary Authorisation without needing special IAM permissions to edit the policy. You only need standard Kubernetes permissions to deploy workloads.

The security mechanism here is not prevention, but auditing. When you use this bypass, GKE admits the deployment but immediately generates a high-severity entry in Cloud Audit Logs.

To bypass the check, simply add the break-glass annotation to your Pod specification:

yaml
123456789
apiVersion: v1
kind: Pod
metadata:
labels:
image-policy.k8s.io/break-glass: "true"
spec:
containers:
- name: nginx
image: nginx:latest

This will allow the deployment but will generate a specific "Break Glass" entry in Cloud Audit Logs, alerting your security team that an emergency bypass occurred.

Addendum: Troubleshooting Common Failures

Even with a perfect setup, deployments can fail. Use this guide to diagnose the most common Binary Authorisation errors.

1. Error: Denied by Attestor

  • The deployment is blocked with a message stating Image ... denied by attestor .... The image was not signed, or the signature does not match the specific Attestor defined in the policy.
  • Fix:
    • Verify Execution: Check Cloud Build logs to ensure the "Sign" step ran successfully.
    • Check Digest: Ensure you are deploying the exact image digest (e.g., image@sha256:abc...) that was built. Binary Authorisation blocks mutable tags like :latest by default because they can change after signing.

2. Error: PermissionDenied on KMS

  • The Cloud Build log fails at the signing step with Permission denied. The Cloud Build Service Account is missing the roles/cloudkms.signerVerifier role on the specific cryptographic key.
  • Fix: Re-run the IAM binding command to grant the Service Account access to the specific KeyRing/Key.

3. Error: Attestor not found

  • GKE or Cloud Build complains it cannot locate the Attestor resource. Project mismatch. The command is looking for the Attestor in your current gcloud config project, but the Attestor usually resides in a dedicated security project.
  • Fix: Always specify the flag --attestor-project=my-secure-project explicitly in your CLI commands.

Architectural Analysis

Pros

  • Cryptographic Certainty: Prevents "man-in-the-middle" attacks on your image registry. You know exactly what code is running.
  • Policy-as-Code: Deployment rules are centralised, version-controlled, and auditable.
  • Compliance: Meets strict regulatory requirements for software supply chain security (e.g., SSDF, SLSA).

Cons

  • Complexity: Significant setup overhead involving KMS, IAM, and Container Analysis APIs.
  • Operational Friction: Requires disciplined pipeline management. Developers cannot simply "push and deploy" from their laptops; everything must go through the trusted signer.

Conclusion

Securing the software supply chain is no longer optional. Binary Authorisation provides the missing link between your CI/CD process and your runtime environment, ensuring that the trust you build in your pipeline is cryptographically enforced at the cluster gate. It's a fundamental pillar of a mature DevSecOps posture on Google Cloud.

References & Further Reading

0
Previous PostHybrid Cloud Connectivity: Cloud Interconnect vs. HA VPN for ModernisationNext Post The Global Service Mesh [1/4]: Cloud Service Mesh & Cloud Run
All Articles