How to Deploy Google Cloud Binary Authorization for GKE Container Image Signature Enforcement

In modern DevSecOps pipelines, container images are rapidly built, pushed to registries, and deployed to Kubernetes clusters via highly automated CI/CD workflows. While this agility is essential, it introduces a severe supply chain vulnerability. If a malicious actor compromises your CI pipeline (e.g., stealing Jenkins credentials or modifying a GitHub Actions runner), they could inject a cryptominer, a backdoor, or a vulnerable software package into your container image, push it to your registry, and the Kubernetes cluster would blindly deploy it. To eliminate this risk and enforce a cryptographic chain of custody, Google Cloud Platform (GCP) provides Binary Authorization, a service that mathematically guarantees only verified, securely compiled container images can ever execute on a Google Kubernetes Engine (GKE) cluster.

The Architecture of Binary Authorization

Binary Authorization relies on the concept of cryptographic Attestations. An attestation is a digital signature created by a trusted authority (an Attestor) that certifies a specific container image has successfully passed a required security gate. Security gates could include a vulnerability scan (e.g., ensuring no critical CVEs exist in the image), a QA testing phase, or a manual approval by a release manager.

When you attempt to deploy a new Pod into a GKE cluster (via kubectl or an automated CD pipeline), the Kubernetes API server intercepts the deployment request using an Admission Controller webhook. The Admission Controller queries the Google Cloud Binary Authorization API. If the required attestations (digital signatures) for that exact container image digest do not exist in the GCP metadata store, the GKE cluster instantly rejects the deployment, throwing a Denied by Binary Authorization error. The malicious image never reaches the execution phase.

Prerequisites for Implementation

To deploy Binary Authorization, you must possess an operational GKE cluster running a compatible version (1.14+). The container images must be stored within Google Artifact Registry (or the legacy Container Registry). Finally, your deployment manifests must reference container images by their immutable cryptographic digest (e.g., image@sha256:abcd123...) rather than a mutable tag (e.g., image:latest).

Configuring the Binary Authorization Policy

First, enable the Binary Authorization API in your GCP project:

gcloud services enable binaryauthorization.googleapis.com

Next, you must enable the feature on your target GKE cluster. This command activates the necessary Admission Controller webhooks within the Kubernetes control plane:

gcloud container clusters update secure-production-cluster \
    --region us-central1 \
    --enable-binauthz

With the cluster configured, you must define the global Binary Authorization policy. By default, the policy is set to “Allow All.” You must restrict it. In the Google Cloud Console, navigate to Security > Binary Authorization and edit the policy.

Set the default rule to Require Attestations. You will be prompted to select an Attestor. If you have not created one, you must do so in the next step.

Creating an Attestor and Signing Images

An Attestor is a cryptographic entity represented by a Cloud KMS (Key Management Service) asymmetric key pair. You must create the Attestor in GCP and link it to a specific KMS key.

# Create the Attestor in Binary Authorization
gcloud container binauthz attestors create vul-scan-attestor \
    --attestation-authority-note=projects/my-project/notes/vul-scan-note \
    --attestation-authority-note-project=my-project

# Bind the Attestor to a Cloud KMS public key
gcloud container binauthz attestors public-keys add \
    --attestor=vul-scan-attestor \
    --keyversion-project=my-project \
    --keyversion-location=global \
    --keyversion-keyring=binauthz-keys \
    --keyversion-key=qa-signer \
    --keyversion=1

In a production workflow, your CI/CD pipeline (e.g., Cloud Build) will build the image, push it to Artifact Registry, and trigger a vulnerability scan. If the scan passes, the pipeline utilizes the private half of the KMS key to cryptographically sign the image digest and upload that signature (the attestation) to the GCP backend.

# Example command a CI pipeline uses to sign a successful build
gcloud beta container binauthz attestations sign-and-create \
    --project=my-project \
    --artifact-url="us-central1-docker.pkg.dev/my-project/repo/app@sha256:abcd123..." \
    --attestor="vul-scan-attestor" \
    --attestor-project="my-project" \
    --keyversion-project="my-project" \
    --keyversion-location="global" \
    --keyversion-keyring="binauthz-keys" \
    --keyversion-key="qa-signer" \
    --keyversion="1"

Verifying the Enforcement

Once the policy is enforced, attempt to deploy an unsigned container image (or an image built outside of your approved CI pipeline) to the GKE cluster using kubectl apply.

The deployment will fail immediately with a highly explicit error message from the API Server: Error from server (Forbidden): error when creating "deployment.yaml": admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image us-central1-docker.pkg.dev/... denied by Binary Authorization default admission rule. Denied by Attestor.

By enforcing Google Cloud Binary Authorization, infrastructure teams mathematically guarantee that software supply chain attacks cannot penetrate production execution environments.