Binary Authorization Admission Control for GKE and Cloud Run

Binary Authorization (opens in a new tab) is a deploy-time admission control that decides whether a container image is allowed to run on Google Kubernetes Engine (GKE) and Cloud Run. A Binary Authorization policy contains evaluation rules that allow an image, block an image, or require verified attestations from named attestors before deployment. At deploy time, traffic flows from the deployment request to the Binary Authorization enforcer, which checks the image digest against the matching rule and verifies required attestations before the platform starts the workload.

1.1How Deployment Verification Works

Deployment verification in Binary Authorization uses cryptographic proof that required checks already passed instead of re-running tests at deploy time. An attestation (opens in a new tab) is a signed statement about a specific immutable image digest affirming that an activity such as vulnerability scanning, regression testing, or build verification was completed. The signature binds the statement to the sha256: digest of the image manifest, so the same attestation authorizes identical images stored in Artifact Registry, Container Registry, or an external registry. Because verification depends on the digest and not the registry URL, moving the same digest between registries does not require a new attestation.

The verification sequence runs in a fixed order:

1. Build image: A pipeline builds a container image with a unique digest.
2. Create attestation: An authorized identity signs the IMAGE_PATH@IMAGE_DIGEST with an attestor signing key to record that the required check passed.
3. Request deployment: Google Kubernetes Engine (GKE) or Cloud Run (opens in a new tab) submits the image digest for deployment.
4. Verify and enforce: Binary Authorization uses each required attestor to verify its attestation on that digest, and the platform deploys the image only after all required attestations verify successfully.

1.2Attestor Infrastructure and Signing Keys

An attestor is the Binary Authorization resource that represents a trusted authority, such as build-secure or prod-qa, that is allowed to vouch for images. Each attestor depends on an Artifact Analysis note resource that stores attestation metadata as occurrences, and each attestor depends on an asymmetric signing key that proves who created the attestation. Attestations can be created with a locally stored key or with a key hosted in Cloud Key Management Service (Cloud KMS), where Cloud KMS protects the private signing material and Binary Authorization verifies with the public key.

Attestors can be created with the Google Cloud console, the Google Cloud CLI, or the REST API, and they can live in a dedicated attestor project separate from the attestation project to support separation of duties. The identity that creates attestations needs roles/containeranalysis.notes.attacher on the note resource associated with the attestor and roles/containeranalysis.occurrences.editor on the project where attestations are stored. Cloud Build users can also use the built-by-cloud-build attestor to deploy only images built by Cloud Build without managing a custom signing workflow.

1.3Default Evaluation Rules

The default rule in a Binary Authorization policy is the baseline evaluation rule that applies to every workload that does not match a more specific rule. A new policy starts with the default rule set to allow all images, which means deployments proceed without attestation checks until the rule is hardened. Changing the default rule is the primary way to establish a secure baseline for an entire project, and the rule is configured through the Google Cloud console or command-line tool.

The default rule supports three peer evaluation modes:

• Allow All Images: Deployments are permitted without attestation verification.
• Disallow All Images: All deployments are blocked unless a narrower rule permits them.
• Require Attestations: Deployment proceeds only after every attestor named in the rule successfully verifies an attestation for the image digest.

1.4Cluster-Specific and Platform-Specific Policies for GKE and Cloud Run

Cluster-specific and platform-specific rules narrow the default rule so different environments can enforce different trust requirements. For GKE, a cluster-specific rule applies to one named GKE cluster and can require attestations even when the default rule is more permissive, so production clusters can demand stronger proof than development clusters. For Cloud Service Mesh, rules can be scoped to a mesh service identity, a Kubernetes service account, or a Kubernetes namespace.

GKE and Cloud Run divide policy responsibility by where enforcement is turned on:

For Cloud Run, revisions flow from the service configuration to the Binary Authorization enforcer before they can serve traffic. If an organization policy requires Binary Authorization for Cloud Run, the per-service verification checkbox is disabled because enforcement is already mandatory.

Binary Authorization (opens in a new tab) is the deploy-time control that decides whether a container image can run on Google Kubernetes Engine (GKE), Cloud Run, and GKE Enterprise. A deployment request flows from the workload definition to the Binary Authorization enforcer, which checks the image against the policy before the platform admits the Pod or service. The policy can block untrusted images, require signed attestations, exempt trusted image paths, and operate in different enforcement modes for testing and emergencies.

2.1Enforcement Modes for Pre-Deployment Checks

Enforcement mode in Binary Authorization controls what happens when an image violates the policy at deploy time. In blocking mode, pre-deployment checks deny the deployment so only images with required attestations can run. In dry-run mode, enforcement is disabled for testing so the deployment is allowed but the violation is logged for review. The deployment depends on both the policy rules and the selected mode, so the same image can be denied in one cluster and allowed with a warning in another.

Choose blocking mode when the policy is ready to protect production from untrusted images. Choose dry-run mode when rolling out a new attestation requirement and measuring impact without breaking existing deployments. Dry-run is therefore a policy-level test setting, not a per-workload exception.

2.2Exempt Images From Trusted Registries

Exempt images in Binary Authorization are container image paths that bypass attestation checks in the policy. Pre-deployment checks block all images that are not in the exempt image list unless they present the required attestations, so the exempt list defines a trust boundary around registries already trusted. Traffic from an exempt path, such as platform infrastructure or hardened base images from a trusted registry, flows directly to admission without attestor verification.

An exemption applies to the image path, not to the workload that uses it, so any Pod referencing that path inherits the bypass. Because exemptions skip verification, the list must stay narrow and limited to registries under direct control. Use attestations for application images that must prove Cloud Build provenance or vulnerability severity compliance, and use exemptions only for system images that cannot be attested.

2.3Break-Glass Emergency Bypass

Break-glass in Binary Authorization is a per-workload override that bypasses enforcement for an emergency deployment. When a Pod or service carries the break-glass annotation, the enforcer allows the image to deploy even if required attestations are missing. The bypass flows from the workload deployer to the enforcer at admission time and applies only to that specific deployment, while the underlying policy remains in blocking mode for all other workloads.

Use break-glass only when an urgent fix must ship before the normal signing process can complete, such as during an outage. The tradeoff is speed versus assurance because the workload runs without proof of build or vulnerability checks. Restrict who can set the annotation and require follow-up remediation, because every use creates a supply-chain gap unless it is reviewed.

2.4Auditing Enforcement Decisions and Continuous Validation

Auditing for Binary Authorization records policy evaluation events and emergency bypasses in Cloud Logging and Cloud Audit Logs. Pre-deployment allow and deny decisions create an auditable trail that shows which image was evaluated, which policy applied, and whether dry-run or break-glass caused an allow. Continuous validation (CV) extends this auditing after deployment by regularly checking running Pods against the current policy throughout the Pod lifecycle.

Continuous validation logs policy non-conformance in Cloud Logging in three key cases:

• Policy changed after deployment: A Pod violates an updated policy after the policy changed post-deployment.
• Dry-run deployment: A Pod was deployed while the policy was in dry-run mode.
• Break-glass deployment: A Pod was deployed with a break-glass override.

Changing enforcement from dry-run to blocking does not retroactively stop running Pods, but continuous validation surfaces them for remediation. Together, pre-deployment enforcement and continuous validation give a complete lifecycle view where blocking prevents new violations and logging tracks historical drift and emergency exceptions.

Binary Authorization (opens in a new tab) turns supply chain checks into deployment enforcement for Google Kubernetes Engine (GKE), Cloud Run, and GKE Enterprise through automated attestation. A continuous integration (CI) pipeline cryptographically signs a container image digest after required gates pass, and the Binary Authorization enforcer verifies those signatures before a Pod or service is allowed to start. The pipeline signs the digest, not the mutable tag, because Binary Authorization looks up attestations by sha256: digest at deploy time.

3.1Attestations as Supply Chain Security Gates

Attestations are digital documents that state a specific container image digest successfully completed a required process. A Binary Authorization policy can require one or more attestations before deployment, so only trusted images from trusted registries deploy and all other images are blocked unless they are in the exempt image list. Common gates enforced this way are build provenance, vulnerability thresholds, and promotion approval, where the image was built by Cloud Build, the image has no vulnerabilities above a specified severity with an allowlist for non-applicable CVEs, and the image passed criteria for promotion from one environment to the next such as development to QA.

3.2Signers, Attestors, and Cryptographic Keys

The attestation workflow separates duties between signers, attestors, and keys to preserve trust. A signer is the automated process that runs in the CI pipeline when an image is built, and it creates the signature using the private key from a cryptographic key pair. An attestor is the Binary Authorization resource that holds the public key and Artifact Analysis note, and the enforcer uses that public key at deploy time to verify the signature in the attestation. Because verification depends on the attestor public key matching the signer private key, protecting the private key in Cloud Key Management Service (Cloud KMS) or a secured local PKIX key is what makes the approval trustworthy.

3.3Automated Signing Workflow in CI Pipelines

The automated signing workflow creates a verifiable link between an immutable image digest and the checks that passed in CI. The pipeline signs the digest because Binary Authorization resolves the digest at admission and fetches attestations bound to that exact digest. A complete workflow moves through an ordered sequence where each step depends on the previous artifact.

1. Generate signature payload: Run gcloud container binauthz create-signature-payload with the artifact URL in the form IMAGE_PATH@IMAGE_DIGEST to create a JSON payload containing the docker reference, manifest digest, and signature type.
2. Sign the payload: Sign the payload file with the private key to produce a signature file, which proves the gate was evaluated for that exact digest.
3. Create the attestation: Upload the signature as an attestation bound to the digest and attestor, using --validate to confirm the configured attestor can verify it.
4. Verify creation: List attestations for the attestor to confirm the record exists before attempting deployment.

The signing operation depends on where the key lives:

3.4Pre-Deployment Enforcement, Gated Promotion, and Observability

Pre-deployment enforcement blocks any image that lacks the attestations required by policy. When a Pod or Cloud Run service requests an image, the enforcer resolves the digest, fetches attestations for each required attestor, and verifies the signatures, and deployment proceeds only after all required verifications succeed. Continuous validation extends that same policy check through the Pod lifecycle by regularly logging conformance in Cloud Logging, including violations when the policy changes after deployment and when Pods were started with dry run or break-glass.

Gated promotion adds human or pipeline approval between environments on top of cryptographic gates. Cloud Deploy provides fully managed delivery to GKE with approvals that approve or deny promotion to a specific target, which prevents unauthorized changes and creates visibility into who approved each stage. Observability closes the loop with continuous scanning where Artifact Registry with Artifact Analysis scans images on upload and updates findings as new vulnerability data arrives, the GKE security posture dashboard checks workloads against Pod Security Standards with severity ratings and Cloud Logging audit trails, and the Cloud Run security panel shows SLSA build level, build provenance, and vulnerabilities for running services.

Key Facts

• Binary Authorization enforces deploy-time admission on Google Kubernetes Engine (GKE) and Cloud Run by verifying attestations bound to the immutable sha256: image digest before a workload starts.
• An attestor represents a trusted authority and depends on an Artifact Analysis note for metadata and an asymmetric signing key managed locally or in Cloud Key Management Service (Cloud KMS).
• A new Binary Authorization policy starts with a default rule that allows all images until it is hardened to disallow all images or require attestations.
• Dry-run mode allows violating images but logs the violation, while break-glass is a per-workload annotation that allows one emergency deployment through an otherwise blocking policy.
• Continuous validation logs running Pods that violate an updated policy or were started with dry-run or break-glass, without retroactively stopping them.