Binary Authorization: Only Deploying Container Images You Can Prove Are Safe
A container registry with push access is, functionally, a way for anyone or anything holding that access to get code running in production — and in most setups, that’s a much larger group of people and systems (CI pipelines, individual engineers with docker push credentials, third-party base images) than the group actually authorized to decide what runs in production. Binary Authorization closes that gap: it’s a deploy-time enforcement control for GKE and Cloud Run that only allows a container image to run if it carries cryptographic proof — an attestation — that it passed whatever checks your policy requires, no matter who or what tried to push it to the registry.
The mental shift this requires is important: Binary Authorization doesn’t ask “is this image safe” at scan time — it asks “can I prove, right now, at deploy time, that this exact image passed the checks I require” and refuses to run anything that can’t answer yes.
The Core Mechanism: Attestations
An attestation is a cryptographically signed statement that a specific container image digest satisfied a specific condition — “this image passed vulnerability scanning,” “this image was built by our CI pipeline, not pushed manually,” “this image passed security team review.” Binary Authorization doesn’t inspect the image itself; it checks whether the required attestations exist and are validly signed.
Build pipeline builds image │ ▼Image pushed to Artifact Registry (assigned a content-addressable digest) │ ▼CI pipeline runs vulnerability scan ──► Passes ──► Sign attestation with Cloud KMS key │ ▼Deploy request to GKE / Cloud Run │ ▼Binary Authorization admission controller checks: does this image digest have a valid attestation for every required attestor in the policy? │ ┌────┴────┐ Yes No │ │ ▼ ▼ Deploy Deployment allowed blockedBecause attestations are tied to the image’s content digest, not its tag, you can’t defeat the check by re-pushing a different image under the same tag — the digest changes, and the attestation no longer applies. This is a meaningful security property tags alone don’t provide, since tags are mutable pointers that can be silently repointed.
Setting Up an Attestor and Policy
# Create a Cloud KMS key to sign attestationsgcloud kms keys create binauthz-attestor-key \ --location=us-central1 \ --keyring=security-keys \ --purpose=asymmetric-signing \ --default-algorithm=ec-sign-p256-sha256
# Create the attestorgcloud container binauthz attestors create vuln-scan-passed \ --attestation-authority-note=projects/my-project/notes/vuln-scan-note \ --attestation-authority-note-project=my-project
# Sign an attestation for a specific image digest after it passes scanninggcloud container binauthz attestations sign-and-create \ --artifact-url="us-docker.pkg.dev/my-project/repo/app@sha256:abc123..." \ --attestor=vuln-scan-passed \ --attestor-project=my-project \ --keyversion-key=binauthz-attestor-key \ --keyversion-location=us-central1 \ --keyversion-keyring=security-keys \ --keyversion=1The policy itself, applied at the project or cluster level, defines which attestors are required before any deployment is allowed:
defaultAdmissionRule: requireAttestationsBy: - projects/my-project/attestors/vuln-scan-passed - projects/my-project/attestors/built-by-ci enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOGRequiring multiple attestors composed together — “passed vulnerability scanning” AND “built by the trusted CI pipeline, not pushed manually” — is a materially stronger guarantee than either check alone, since it closes both the “vulnerable image” gap and the “unauthorized image source” gap simultaneously.
Walking Through an Attack This Actually Prevents
The abstract description of Binary Authorization is easy to nod along to and hard to viscerally appreciate without a concrete scenario. Here’s the failure mode it’s specifically designed to stop.
Notice what this scenario assumes: the attacker has legitimate push access to the registry (a compromised CI token, a leaked credential — a realistic scenario, not a contrived edge case) but does not have access to the attestor signing key, because that key is scoped far more narrowly. Registry push access and attestation-signing access are deliberately different privilege levels, and that separation is what makes the control meaningful — if the same credential could do both, Binary Authorization would only be adding friction, not real security.
Binary Authorization vs Vulnerability Scanning Alone
It’s worth being precise about what problem this solves that scanning alone doesn’t, since the two are often conflated.
┌────────────────────────┬───────────────────────────────────────┐│ Approach │ What it actually guarantees │├────────────────────────┼───────────────────────────────────────┤│ Vulnerability scanning │ This image was scanned and the ││ alone (no enforcement) │ result is visible in a dashboard — ││ │ nothing stops a vulnerable image ││ │ from being deployed anyway ││ Binary Authorization │ This exact image digest cannot run ││ (with scan-based attestor) │ unless the scan attestation exists ││ │ and is validly signed — enforcement, ││ │ not just visibility │└────────────────────────┴───────────────────────────────────────┘A lot of organizations run vulnerability scanning and assume they’re covered, without realizing scanning alone is purely informational unless something actually blocks deployment based on the result. Binary Authorization is the piece that turns “we scan our images” into “we cannot deploy an image that failed scanning,” which is a meaningfully different and stronger guarantee — the gap between having a smoke detector and having a fire suppression system that actually activates.
Dry-Run Mode: Rolling Out Without Breaking Deploys
Enabling Binary Authorization in full enforcement mode against an existing deployment pipeline that has no attestation infrastructure yet is a guaranteed outage. DRYRUN_AUDIT_LOG_ONLY mode exists specifically to avoid that:
defaultAdmissionRule: requireAttestationsBy: - projects/my-project/attestors/vuln-scan-passed enforcementMode: DRYRUN_AUDIT_LOG_ONLYIn this mode, deployments that would have been blocked are logged, not actually blocked — giving the team a real window to build out the attestation-signing steps in CI, verify every legitimate deployment path is covered, and only flip to enforcement once the audit logs show zero unexpected blocks. Skipping this step is the single most common reason teams have a bad first experience with Binary Authorization.
Real-World Use Case: Enforcing “No Manual Deploys to Production”
A common and genuinely high-value policy: production deployments must be built and attested exclusively by the CI pipeline, never pushed manually by an engineer running docker push and kubectl apply from their laptop, even in an emergency. This isn’t about distrusting engineers — it’s about guaranteeing that every production image has a traceable build provenance (which commit, which pipeline run, what tests passed) rather than relying on process discipline alone, which breaks down under exactly the kind of time pressure an incident creates. The attestor requiring “built by CI” makes this a technical guarantee instead of a policy document nobody reads during a 2 AM outage.
Best Practices
- Always roll out new attestor requirements in dry-run mode first, reviewing audit logs for at least one full deployment cycle before enforcing.
- Compose multiple attestors for layered guarantees rather than relying on a single broad check — vulnerability scan, build provenance, and manual security review (for particularly sensitive services) are each catching a different failure mode.
- Scope attestor signing keys tightly in IAM. The whole security model collapses if the key used to sign attestations is broadly accessible — treat it with the same care as a production credential, because functionally, that’s exactly what it is.
- Include a documented, audited break-glass exception path. Emergencies happen; the answer isn’t disabling Binary Authorization entirely under pressure, but having a pre-approved, logged exception process for genuinely urgent situations.
- Apply stricter policies to production than to lower environments. Development and staging clusters often benefit from faster iteration without full attestation overhead, while production is exactly where the enforcement guarantee matters most — a tiered policy reflects that difference deliberately rather than applying one blanket rule everywhere.
Common Mistakes
Enabling enforcement mode without dry-run validation first. This reliably blocks legitimate deployments the moment enforcement flips on, usually during a deploy someone didn’t expect to be affected.
Treating “passed vulnerability scan” as the only attestation worth requiring. A scan-only policy still allows anyone with registry push access to deploy a scanned-but-unauthorized image — build provenance attestation closes a different, equally real gap.
Not rotating or protecting the attestor signing key with the same rigor as other production secrets. A compromised signing key defeats the entire attestation model, since an attacker with that key can sign attestations for malicious images.
Forgetting to update attestation policy when the CI pipeline itself changes. A pipeline migration or a new build tool that changes how images are produced can silently break attestation generation — treating this as infrastructure that needs monitoring, not a one-time setup, avoids a gap where deploys either fail unexpectedly or, worse, an alternate unattested path quietly emerges.
Frequently Asked Questions
Does Binary Authorization scan images for vulnerabilities itself? No — it enforces that required attestations exist; the actual scanning (via Artifact Analysis or a third-party scanner) is a separate step in your pipeline that then signs an attestation based on the scan result.
Can Binary Authorization be bypassed by pushing directly to the cluster’s node? No — enforcement happens at the Kubernetes admission controller level (for GKE) or the Cloud Run deployment API level, intercepting every deployment attempt regardless of how it’s initiated, not just deployments through a specific pipeline.
What happens to already-running workloads when a new policy is enforced? Binary Authorization evaluates at deploy time, not continuously against already-running pods — existing workloads keep running until their next deployment or restart triggers re-evaluation against the current policy.
Is Binary Authorization required for all GKE clusters? No, it’s an opt-in feature you enable per cluster or project — many teams run GKE without it, though it’s increasingly considered a baseline control for production clusters handling sensitive workloads.
Does this slow down deployments noticeably? The admission check itself is fast — a lookup against existing attestations, not a live scan — so it adds negligible latency to the deploy process itself. The real time cost is upfront: building out the CI steps that generate attestations in the first place.
Can different clusters or namespaces have different Binary Authorization policies? Yes — policies can be scoped per project, and cluster-specific rules can override the project default, which is useful for applying stricter requirements to production clusters than to development or staging environments where faster iteration matters more than deploy-time enforcement.
What happens if the attestor’s signing key is deleted or destroyed? Existing signed attestations remain valid for verification (they’re independently stored records), but new attestations can no longer be signed with that key — losing a signing key without a recovery plan means the CI pipeline can no longer produce new deployable images until a replacement attestor and key are provisioned and wired into the pipeline.
Summary
Binary Authorization converts “we trust our deployment process” from an assumption into something you can technically enforce and prove — every production image either carries valid, current attestations from your required checks, or it simply doesn’t run, regardless of who tried to deploy it or how. The rollout discipline matters as much as the feature itself: dry-run first, compose multiple attestors for layered coverage, and protect the signing keys as carefully as any other production credential, since they’re the actual root of trust the whole system rests on — and a system’s guarantees are never stronger than the weakest-protected key underneath them, no matter how sound and well-reasoned the rest of the design otherwise is.