Binary Authorization Attestors and Deployment Policy

Vulnerability Integration and Emergency Workflows connect automated image scanning to deploy-time control while keeping an emergency path for urgent fixes. In this design, Artifact Analysis (opens in a new tab) scans container images and stores vulnerability results, Binary Authorization (opens in a new tab) enforces a policy that requires proof of that check before deployment, and emergency bypasses still leave an audit trail. The scan alone never blocks deployment, and enforcement happens only when the policy requires a matching attestation for Google Kubernetes Engine (GKE) (opens in a new tab), Cloud Run (opens in a new tab), or Google Distributed Cloud.

1.1Vulnerability Scanning with Artifact Analysis

Artifact Analysis is the service that supplies the vulnerability information that Binary Authorization uses to control deployment. When an image is pushed to Artifact Registry, Artifact Analysis can automatically scan it for known vulnerabilities and store the results as trusted metadata. A developer or pipeline can also send an artifact to the On-Demand Scanning API from a local environment or from a CI/CD step such as a Cloud Build build step. That scan output flows from Artifact Analysis to a trusted signer that decides whether the image is clean enough to promote.

A typical vulnerability gate approves an image only when it meets deployment criteria defined by the organization, such as:

• No known vulnerabilities with a severity above Medium
• Source code is from a trusted source repository
• A trusted build service ran the build
• Build artifacts are from a trusted artifact repository

If the image meets the severity rule, a trusted authority creates a vulnerability attestation for that exact registry path and digest. If specific findings do not apply to the application, they can be added to an allowlist so the attestation can still be issued for an image with those findings.

1.2Enforcing Vulnerability Policy at Deploy Time

Binary Authorization is the deploy-time enforcer that allows or blocks container deployment based on policy rules. The policy can require a vulnerability attestation that proves the image passed the severity check, and the enforcer verifies the attestation signature instead of rescanning the image. Pre-deployment checks can also block every image that is not on the exempt image list, so only images from trusted registries can even reach the attestation check.

Vulnerability enforcement follows the same promotion lifecycle that Binary Authorization protects:

1. Build and unit testing: image is built and scanned for vulnerabilities.
2. Development deployment: image deploys where users are not affected.
3. QA deployment: image deploys where only internal users are affected.
4. Canary deployment: image deploys where only a fraction of external users are affected.
5. Production deployment: image deploys broadly after passing prior stages.

Each stage can use its own environment, such as a separate GKE cluster or Google Cloud project, with its own Binary Authorization policy. An image moves from one stage to the next only after its required attestations, including the vulnerability attestation, verify successfully for that environment.

1.3Emergency Bypass and Auditability

Emergency Bypass and Auditability provide a controlled way to ship a critical fix without losing visibility into what was allowed. When an urgent fix must reach production before a scan or signature is complete, the deployment can proceed through an exemption path, such as an exempt image entry, rather than satisfying the normal attestation rule. The request still flows from the platform, such as GKE or Cloud Run, through the Binary Authorization enforcer, so the bypass is a policy decision and not an unmonitored side door.

Auditability is maintained because allowed and blocked decisions both produce logs throughout the workload lifecycle. When enforcement blocks an image, Binary Authorization writes the reason to Cloud Audit Logs, and when continuous validation is enabled, it regularly checks running Pods against the current policy and writes conformance results to Cloud Logging. This post-deploy monitoring matters because a policy can change after deployment, and continuous validation will then log Pods that violate the updated rule even though they were allowed at deploy time.

Use enforcement when defective or vulnerable software must not start, and use continuous validation when already-running workloads must stay visible against evolving vulnerability policy.

Attestor Management and Cryptographic Verification ensure that only trusted container images deploy to production through signed proof of required checks. In this model, Binary Authorization (opens in a new tab) enforces the deployment policy, an attestor acts as the trusted verification authority, and an attestation acts as the signed statement that proves approval happened. Together they control whether an image moves through the CI/CD pipeline from development to testing to production.

2.1Attestors as Trusted Verification Authorities

An attestor is the party responsible for verifying that a required process completed before a container image can be deployed. The attestor can be a human user or, more often, a machine process such as a build system, test system, or continuous integration and continuous delivery (CI/CD) pipeline. In a multi-stage pipeline, different attestors can represent each gate, so an image cannot move from development to testing to production until all required attestors have approved it.

The attestor holds the public key used for verification and is typically managed by people responsible for software supply-chain security. A Binary Authorization policy lists which attestors must approve an image, and at deployment time the Binary Authorization enforcer checks that all required attestations are present and valid. If the image passes all constraints, the enforcer allows deployment to Google Kubernetes Engine (GKE) (opens in a new tab); otherwise deployment is blocked until the image becomes compliant.

2.2Artifact Analysis Notes That Support Attestors

An Artifact Analysis note is the trusted metadata record that backs an attestor in Binary Authorization. Creating an attestor requires linking the attestor to a note that stores attestation metadata used during authorization. The note is created through the Artifact Analysis global API endpoint, because Binary Authorization does not support regional storage or regional endpoints.

Setting up an attestor in a multi-project configuration separates duties across ownership boundaries:

Creating a usable attestor requires completing related access grants so the deploy-time check can read verification data:

• Create the Artifact Analysis note and the attestor itself in the attestor project, associating the note with the attestor.
• Add an Identity and Access Management (IAM) binding that grants the deployer project service account the roles/binaryauthorization.attestorsVerifier role on the attestor.
• Grant both the attestor and deployer service accounts the roles/containeranalysis.notes.occurrences.viewer role on the Artifact Analysis note.
• Register a cryptographic public key with the attestor so signatures can be verified.

Without these bindings, the Binary Authorization enforcer cannot access the attestor or its associated attestations when it evaluates policy.

2.3Cryptographic Key Pairs and Cloud Key Management Service

A Public-Key Infrastructure (X.509) (PKIX) key pair provides the cryptographic identity for an attestor in Binary Authorization. The pair consists of a private key kept secret by the signer and a public key stored in the attestor. The recommended algorithm is Elliptic Curve Digital Signature Algorithm (ECDSA), such as ec-sign-p256-sha256, and keys generated and stored by Cloud Key Management Service (KMS) are PKIX-compliant. RSA, PGP, and post-quantum cryptography keys can also be used for signing.

The private key signs the container image digest to produce a digital signature, and that signature is stored in an attestation. The public key remains with the attestor so the Binary Authorization enforcer can verify the signature at deploy time. This separation means compromise of the public key does not allow forgery, while protection of the private key in Cloud KMS ensures only verified signers can authorize images.

2.4Signing Images and Verifying at Deployment

An attestation is a signed statement that a required pipeline check, such as vulnerability scanning or QA approval, is complete for a specific image digest. The signer creates the attestation after checks pass, and Artifact Analysis stores it as an occurrence linked to the attestor note. Because the attestation binds to the immutable image digest rather than a mutable tag, changing the image contents requires a new attestation.

The end-to-end flow moves data from the signer to the registry to the enforcer in order:

1. Define policy: An administrator creates a Binary Authorization policy that names the trusted attestors and any other criteria for deployment.
2. Generate keys: The attestor generates a cryptographic key pair, keeping the private key secret in Cloud KMS.
3. Sign image: The signer uses the private key to sign the image digest, producing a unique digital signature.
4. Store attestation: The signature is attached to the image as attestation metadata stored in the image registry and Artifact Analysis.
5. Register public key: The public key is added to the attestor so Binary Authorization can use it for verification.
6. Request deployment: When a Pod deployment is requested, the enforcer retrieves the attestation attached to the image.
7. Verify and decide: The enforcer uses the registered public key to verify the signature and checks all policy constraints, then moves the request to allowed or blocked.

In an emergency, deployment can bypass policy through the breakglass workflow, and every breakglass use is recorded in Cloud Audit Logs. This preserves auditability while ensuring that normal deployments depend on cryptographic proof that all required attestors verified the image.

Policy Configuration and Enforcement Logic define how Binary Authorization (opens in a new tab) controls which container images can run on supported platforms. A project-singleton policy is the set of rules stored in a Google Cloud project that governs deployment, and a deploy-time enforcer allows or blocks each deployment based on that policy. This model lets teams define required checks once for Google Kubernetes Engine (GKE) (opens in a new tab), Cloud Run, and Google Distributed Cloud and have them enforced automatically.

3.1Policy Model

The Binary Authorization policy model defines the deployment rules that an image must satisfy before it can run. A policy is a collection of rules, and each rule provides specific criteria such as requiring a verified attestation that proves a build, test, or approval step was completed. At deploy time the enforcer checks the image registry path and digest against the policy, allows the image when it conforms, and blocks it when it does not. Blocked deployments generate a message in Cloud Audit Logs that describes why the image is out of compliance.

Each deployment stage can have its own environment and criteria, such as development, QA, canary, and production clusters or projects. Binary Authorization defines the rules for moving an image from one stage to the next and enforces those rules without redoing the earlier work. Instead of rebuilding or retesting, the enforcer verifies a digitally signed attestation from a trusted authority.

3.2Evaluation Modes

The evaluationMode setting controls whether a cluster enforces the project-singleton policy for its workloads. The setting is configured in the cluster specification for Google Distributed Cloud, and the same concept applies to enabling enforcement on a supported platform. When enforcement is on, Pod creation requests are validated against the policy in the fleet host project; when it is off, no validation occurs.

3.3Enforcement Scope and Prerequisites

Enforcement Scope and Prerequisites combine a project-wide policy with per-cluster enablement and required setup. The project-singleton policy is associated with a Google Cloud project and specifies the rules, while each cluster opts in through its own evaluation mode. This allows one project policy to govern multiple clusters, with each cluster independently enabled for enforcement during creation or updated later to enable or disable it.

Before a cluster can enforce the policy, three dependencies must be satisfied. The cluster must be registered with a fleet through the fleet host project, the Binary Authorization API (binaryauthorization.googleapis.com) must be enabled in that project, and the Kubernetes service account binauthz-system/binauthz-agent must hold the Binary Authorization Policy Evaluator role (roles/binaryauthorization.policyEvaluator). The flow depends on all three sides working together:

• Fleet registration links the on-premises or cloud cluster to the fleet host project that holds the policy.
• The enabled API provides policy-based validation for images deployed to the cluster.
• The Policy Evaluator role allows the agent on the cluster to read and evaluate that policy.

If any prerequisite is missing, Pod creation can fail with a validation error that directs the operator to enable the API and grant the Policy Evaluator role.

Key Facts

• Binary Authorization blocks container deployment at deploy time when the policy requires an attestation and the image lacks a valid one, while Artifact Analysis scanning alone only produces findings.
• An attestation binds a digital signature created with a private key to an immutable image digest, and the Binary Authorization enforcer verifies that signature with the public key stored in the attestor.
• A Binary Authorization attestor must be linked to an Artifact Analysis note created through the global API endpoint, with IAM bindings that let the deployer service account verify attestors and view note occurrences.
• PROJECT_SINGLETON_POLICY_ENFORCE enforces the project-singleton policy on a cluster, while DISABLE allows images to deploy without policy validation.
• Binary Authorization enforcement blocks non-compliant deployments and logs the reason to Cloud Audit Logs, while continuous validation lets running Pods continue but logs non-conformance to Cloud Logging.