GKE Binary Authorization

Binary Authorization (BinAuthz) is a Google Cloud security service that enforces deployment-time policy validation for container images on GKE clusters. It ensures that only images that have been signed by trusted authorities (attestors) can be deployed. This prevents the deployment of unverified, potentially vulnerable, or malicious container images. The primary use case is to enforce a software supply chain security policy, ensuring that images have passed through required checks (e.g., vulnerability scanning, code review) before reaching production.

Binary Authorization works by integrating with GKE's admission control mechanism. When a pod creation request is made, the BinAuthz admission controller intercepts the request, checks the policy, and either allows or denies the deployment. It can be configured in two modes: Project Single Key (simpler, but less flexible) and Project Attestors (recommended for production).

The core mechanism involves three main components: Attestors, Attestations, and Policy. An attestor is a Google Cloud resource that represents a trusted authority. It contains a PGP public key or a PKIX public key that can verify signatures. An attestation is a cryptographically signed statement that an image is approved. The attestation is created by signing the image's digest with the attestor's private key. The policy defines which attestors are required and under what conditions images are allowed.

When a pod is created, the admission controller checks the container image reference. If the image is not in the exemption list, the controller retrieves the attestations stored in Container Analysis (a metadata service that stores image vulnerability and attestation data). It then verifies that the attestations are valid (signed by a key that matches an attestor in the policy) and that the number of required attestations is met. If verification fails, the pod creation is denied with an error message.

To configure Binary Authorization, follow these steps:

gcloud services enable containeranalysis.googleapis.com

gcloud container binauthz attestors create my-attestor \
    --attestation-authority-note my-note \
    --note-project-id PROJECT_ID

gcloud container binauthz attestors public-keys add \
    --attestor my-attestor \
    --pgp-public-key-file key.pub

gcloud container binauthz attestations create \
    --artifact-url gcr.io/PROJECT_ID/my-image@sha256:DIGEST \
    --attestor my-attestor \
    --signature-file signature.bin \
    --public-key-id KEY_ID

gcloud container binauthz policy set policy.yaml

Where policy.yaml contains:

defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
    - projects/PROJECT_ID/attestors/my-attestor

gcloud container clusters create my-cluster \
    --enable-binauthz \
    --zone us-central1-a

Verification:

A large bank wants to ensure that only images that have passed vulnerability scanning and been signed by the security team can run on production GKE clusters. They set up a CI/CD pipeline with Cloud Build. After each successful build, Cloud Build triggers a vulnerability scan via Container Analysis. If no critical vulnerabilities are found, a signing step runs that creates an attestation using a private key stored in Cloud KMS. The attestation is uploaded to Container Analysis. The production cluster has Binary Authorization enforced with a policy that requires attestation from the security team's attestor. Developers can deploy to dev clusters without enforcement. This prevents deployment of unverified images to production. Common issues include forgetting to rotate keys and mismatched note references. The bank runs 50 clusters with over 1,000 deployments per day; Binary Authorization adds negligible latency (under 100ms).

A large e-commerce company has multiple development teams. Each team must have their images signed by both a team lead and a security auditor. They create two attestors: one for team leads and one for security. The policy requires attestations from both attestors. Developers create attestations using their own keys (team lead attestor) and then submit a request to security for the second attestation. This ensures two-person rule for production deployments. The company uses exemption patterns for base images from an internal trusted registry. Misconfiguration often occurs when the policy requires attestations from attestors that do not exist or when the note IDs conflict. They monitor audit logs for denied deployments to detect unauthorized attempts.

A healthcare startup wants to adopt Binary Authorization but is concerned about breaking existing deployments. They first enable Binary Authorization in dry-run mode (evaluationMode: REQUIRE_ATTESTATION with enforcementMode: DRYRUN_AUDIT_LOG_ONLY). This logs whether a deployment would be denied but does not block it. They analyze logs over a week to identify images that lack attestations. Once they have signed all necessary images, they switch to ENFORCED_BLOCK_AND_AUDIT_LOG. This gradual approach is common in production migrations. The startup also uses Cloud Scheduler to periodically check for unsigned images and alert the security team.