Binary Authorization overview

This document provides an overview of Binary Authorization.

What is Binary Authorization?

Binary Authorization is a Google Cloud product that you can use to implement software supply-chain security measures when you develop and deploy container-based applications.

What does Binary Authorization do?

You can use Binary Authorization to do the following:

What platforms does Binary Authorization support?

Binary Authorization supports the following platforms:

Binary Authorization is part of a deployment architecture that includes the following related products:

  • Artifact Registry, Container Registry and other registries that store the images you want to deploy.
  • Artifact Analysis provides vulnerability information that you can use with Binary Authorization to control deployment. Separately, Artifact Analysis stores trusted metadata that is used in the authorization process.
  • Security monitoring, a dashboard you can use to assess your application security posture across interdependent Google Cloud products, including Binary Authorization.
  • Cloud Build, which produces attestations and provenance that Binary Authorization can use for enforcement and monitoring.
  • Cloud Deploy is a managed continuous-delivery service, which automates delivery of applications to a series of target environments in a defined sequence.

Binary Authorization is based on the Kritis specification, which is part of the Grafeas open source project.


Software supply chain security aims to ensure that software is sourced, built, tested, released, and deployed according to internal best practices and standards.

Container-based architectures allow teams to develop highly decoupled systems—for example, those based on microservices architectures—and encourages the use of short-lifecycle development practices, including continuous integration (CI) and continuous deployment (CD).

In a container-based development environment, images can be deployed on a succession of clusters—such as testing, staging and release—which are part of the software supply chain.

Binary Authorization aims to reduce the risk of deploying defective, vulnerable, or unauthorized software in this type of environment. Using this service, you can prevent images from being deployed unless it satisfies a policy you define.

While Binary Authorization does not prescribe internal processes or best practices it helps you enforce your own practices by restricting deployment of images that have not passed your required checks.


A deployment lifecycle for images can consist of the following stages, where completing one stage is a prerequisite for progression to the next one—for example:

  1. Build and unit testing
  2. Deployment into a development environment where users aren't affected
  3. Deployment into a QA environment, where only internal users are affected
  4. Deployment into a canary environment, where only a fraction of external users are affected
  5. Deployment into production

Each stage can have its own deployment environment—for example, a GKE cluster or a Google Cloud project—and its own criteria that must be satisfied before an image can move onto the next stage. Binary Authorization allows you to define the rules by which an image passes from one stage to another and it provides the means for enforcing those rules.


The most common Binary Authorization use cases involve attestations. An attestation certifies that a specific image has completed a previous stage, as described previously. You configure the Binary Authorization policy to verify the attestation before allowing the image to be deployed. At deploy time, instead of redoing activities that were completed in earlier stages, Binary Authorization only needs to verify the attestation.

Use cases involving attestations include the following:

  • Build verification, in which Binary Authorization uses attestations to verify that an image was built by a specific build system or continuous integration (CI) pipeline.

    To learn how to set up a CI pipeline, based on Cloud Build, that can create an attestation, see Cloud Build integration.

  • Vulnerability scanning, where the CI-built image has also been scanned for vulnerabilities by Artifact Analysis. In this case, the attestation is only created if identified vulnerabilities satisfy a vulnerability signing policy.

    Learn how to set up a vulnerability-scanning CI pipeline with Voucher or Kritis Signer.

  • Manual check, where a person, for example, a QA representative, manually creates the attestation.

    To learn how to manually create an attestation, see Create attestations.

See Get started with the Google Cloud console for an end-to-end attestation tutorial.


Binary Authorization provides:

  • A policy model that lets you describe the constraints under which images can be deployed
  • An attestation model that lets you define trusted authorities who can attest or verify that required processes in your environment have completed before deployment
  • A deploy-time enforcer that prevents images that violate the policy from being deployed

Policy model

Binary Authorization implements a policy model, where a policy is a set of rules that governs the deployment of container images. Rules in a policy provide specific criteria that an image must satisfy before it can be deployed.

For more information about the Binary Authorization policy model and other concepts, see Key concepts.


To set up Binary Authorization, you must first enable the service for the Google Cloud projects that comprise your deployment and authorization pipeline.

You then define the policy that specifies the constraints under which container images can be deployed. If your policy requires attestations before deployment, you must also set up attestors that can verify attestations before allowing associated images to deploy.

To set up Binary Authorization, see the following guides:


Before an image can be deployed, any required signers must create an attestation that verifies that the image is ready to move to the next deployment stage. The attestation is a record that contains the registry path and digest of the image, and that has been digitally signed using the signer's private cryptographic key.

For more information on authorization, see Use attestations.


When you deploy an image, Binary Authorization checks the policy and enforces any rule it finds that governs its deployment.

If the image passes the constraints defined in the policy, Binary Authorization allows it to be deployed. If not, the service blocks deployment and writes a message to Cloud Audit Logs that describes why the image is out of compliance.

To view Binary Authorization enforcement events in Cloud Audit Logs, see the following guides:

For more information on deployment, see the following guides:

Continuous validation

Continuous validation (CV) with check-based platform policies is a feature of Binary Authorization that periodically checks the metadata of container images associated with running Pods for continued policy conformance.

Learn more about CV.

Secure Binary Authorization with VPC Service Controls

VPC Service Controls improves your ability to mitigate the risk of unauthorized copying or transfer of data from your Google-managed services and resources.

For more information about securing Binary Authorization-related resources, see Secure with VPC Service Controls.

Software Delivery Shield

Binary Authorization is part of the Software Delivery Shield solution. Software Delivery Shield is a fully-managed, end-to-end software supply chain security solution that helps you to improve the security posture of developer workflows and tools, software dependencies, CI/CD systems used to build and deploy your software, and runtime environments such as Google Kubernetes Engine and Cloud Run. To learn how you can use Binary Authorization with other components of Software Delivery Shield to improve the security posture of your software supply chain, see Software Delivery Shield overview.

What's next