Binary Authorization for Supply Chain Security

Binary Authorization (BinAuthz) is a Google Cloud service that provides deploy-time security for container-based applications on Google Kubernetes Engine (GKE). It ensures that only trusted container images are deployed by enforcing policies that require images to be signed (attested) by approved authorities. BinAuthz is part of the Google Cloud supply chain security framework, which includes Cloud Build, Artifact Registry, and Container Analysis.

Container images can be tampered with at any point in the supply chain: during build, while stored in a registry, or during transit. Without verification, an attacker could inject malware into an image and deploy it to a production cluster. BinAuthz mitigates this by requiring that every image deployed to a GKE cluster has a valid attestation from a trusted authority. This ensures that only images that have passed through a controlled build and signing process are allowed to run.

Binary Authorization operates at the admission controller level in GKE. When a pod creation request is made (e.g., via kubectl apply), the GKE API server triggers an admission webhook that calls the Binary Authorization service. The service checks the image reference against the configured policy. The policy specifies which attestors (trusted authorities) must sign the image. An attestor is a resource that represents a trusted party, such as a Cloud KMS key or a PGP key. The attestor is associated with a public key. The image must have a corresponding attestation (a signed statement) that proves it was built and approved by that attestor.

The attestation is stored in Container Analysis, a metadata service that records vulnerabilities and attestations for container images. When an image is pushed to Artifact Registry, Cloud Build can automatically create an attestation using the gcloud container binauthz attestations create command. The attestation includes the image URL, the attestor name, and a cryptographic signature.

Enable Binary Authorization on a GKE cluster:

gcloud container clusters update CLUSTER_NAME --region=REGION --enable-binauthz

Create an attestor:

gcloud container binauthz attestors create ATTESTOR_NAME \
    --attestation-authority-note-project=PROJECT_ID \
    --attestation-authority-note=NOTE_ID

Add a public key to an attestor (using Cloud KMS):

gcloud container binauthz attestors add-iam-policy-binding ATTESTOR_NAME \
    --member="serviceAccount:SERVICE_ACCOUNT" \
    --role=roles/binaryauthorization.attestorsVerifier

Create an attestation:

gcloud container binauthz attestations create \
    --artifact-url="LOCATION-docker.pkg.dev/PROJECT_ID/REPO/IMAGE@sha256:DIGEST" \
    --attestor=ATTESTOR_NAME \
    --keyversion-project=PROJECT_ID \
    --keyversion-location=LOCATION \
    --keyversion-keyring=KEYRING \
    --keyversion-key=KEY \
    --keyversion=KEY_VERSION

View the policy:

gcloud container binauthz policy export

Set a policy that requires at least one attestation:

gcloud container binauthz policy import policy.yaml

Sample policy YAML:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
requireAttestationsBy:
  - projects/PROJECT_ID/attestors/ATTESTOR_NAME

A large bank uses GKE to run payment processing applications. Regulatory compliance (PCI DSS) requires that all container images be signed and verified before deployment. The bank implements Binary Authorization with Cloud KMS. They create an attestor for each line of business. Cloud Build is configured to automatically sign images after a successful build and vulnerability scan. The policy is set to require at least one attestation from the line-of-business attestor. In production, if an image is deployed without an attestation (e.g., from a developer's laptop), the deployment is blocked. The bank also uses dry-run mode in development clusters to test policies without blocking. Scaling considerations: each cluster has up to 100 nodes, and the admission webhook adds about 100ms latency per pod creation. Misconfiguration: initially, the bank forgot to grant the GKE service account the binaryauthorization.attestors.verify role, causing all deployments to fail with permission errors.

A SaaS company runs multi-tenant GKE clusters where each customer's workloads are isolated in separate namespaces. They use Binary Authorization to ensure that only images built by their CI/CD pipeline are deployed, preventing customers from deploying arbitrary images. They create a single attestor for the entire company. The policy has a default rule requiring attestation, but they add an exception for system images (e.g., gke.gcr.io/*) using an alwaysAllow rule. They also use cluster-specific rules: for production clusters, enforcement mode is ENFORCED_BLOCK_AND_AUDIT_LOG; for staging clusters, it is DRYRUN_AUDIT_LOG_ONLY. Common issues: developers often try to deploy images by tag instead of digest, causing attestation mismatches. The team educates developers to always use digest references. Performance: with hundreds of pods being created simultaneously, the admission controller handles the load without issues.

A tech company uses many open-source images from Docker Hub. They want to ensure these images are not tampered with. They use Binary Authorization with a third-party attestor service (e.g., from a vendor that signs verified images). They configure the policy to require attestation from the vendor's attestor. However, not all open-source images have attestations. They use a combination of allowlisting specific image repositories and requiring attestation for others. This hybrid approach reduces friction while maintaining security. Misconfiguration: they initially set the policy to require attestation for all images, breaking deployments of images without attestations. They learned to use alwaysAllow rules for trusted registries.