This document contains an overview of Binary Authorization.


Binary Authorization is a service on Google Cloud that provides software supply-chain security for container-based applications. Binary Authorization extends Google Kubernetes Engine (GKE) and Anthos clusters on VMware with deploy time enforcement of security policies. On Anthos clusters on VMware, Binary Authorization extends this policy enforcement to hybrid-cloud architectures. Binary Authorization works with container images from Container Registry, Artifact Registry and other container image registries.

With Binary Authorization, you can automatically check each component of your software supply chain, ensuring the quality and integrity of your software before an application is deployed to your production environment.

Binary Authorization is part of a deployment architecture that includes:

  • GKE, which runs images in clusters that are hosted on Google Cloud.
  • Anthos clusters on VMware, which runs the images in clusters that are hosted in on-premises data centers.
  • Container Registry, Artifact Registry, and other registries that store the container images you want to deploy.
  • Container Analysis, which stores trusted metadata that is used in the authorization process.
  • Binary Authorization itself, which allows or blocks deployment of images to GKE and Anthos clusters on VMware based on a policy you configure.

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


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 may be deployed on a succession of clusters-such as testing, staging and release-which are part of the software supply chain.

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

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.

Binary Authorization does not prescribe internal processes or best practices around the integrity and quality of your software. Rather, it helps you enforce your own practices by restricting deployment of container images that have not passed your required checks.

Typical use cases

The most common Binary Authorization use cases involve attestations. In these cases, when the container image is built, its unique digest is digitally signed by a signer in order to create an attestation.

At deploy time, the Binary Authorization enforcer uses an attestor to verify the attestation. In this way, only container images with verified attestations are allowed to deploy.

Use cases involving attestations include the following:

  • Build verification, in which Binary Authorization uses attestations to verify that a container image was built by a specific build system or continuous integration (CI) pipeline. To learn how to set up CI pipeline, based on Cloud Build, that can create an attestation, see Cloud Build integration.
  • Vulnerability scanning, where the CI-built container image has also been scanned for vulnerabilities by Container 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 representative, QA for example, manually creates the attestation.

See Getting started with the Google Cloud Console for an end-to-end attestation tutorial.


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

  • Build and unit testing
  • Deployment into a development environment where users aren't affected
  • Deployment into a QA environment, where only internal users are affected
  • Deployment into a canary environment, where only a fraction of external users are affected
  • Deployment into production

After build and testing, each stage has its own deployment environment, here a GKE cluster, and its own criteria that must be satisfied before an image can move onto the next. Binary Authorization allows you to define the criteria for an image to pass from one stage to another and provides the means for enforcing the criteria.


Binary Authorization provides:

  • A policy model that lets you describe the constraints under which container 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
  • Enforcement functionality that prevents wrong, faulty, or unauthorized images from entering your deployment environments

Policy model

Binary Authorization implements a policy model, where a policy is a set of rules that governs the deployment of container images to a GKE cluster. 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 container images to deploy.

For more information on setup steps, see Setting Up Overview.


Before a container 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 container image, and that has been digitally signed using the signer's private cryptographic key.

For more information on authorization, see Creating attestations.


When you deploy a container image to GKE, Binary Authorization checks the policy and enforces any rule it finds that governs its deployment. If the rule requires attestors, Binary Authorization checks to make sure that all attestors have verified the image.

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

For more information on deployment, see Deploying Containers.

Continuous validation

Continuous Validation (CV) is a feature of Binary Authorization that periodically checks container images associated with running Pods for continued policy conformance.

Learn more about CV.

Securing 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 Securing with VPC Service Controls.

What's next