This page contains an overview of Binary Authorization.


Binary Authorization is a service on Google Cloud Platform (GCP) that provides software supply-chain security when deploying container-based applications. Binary Authorization extends Google Kubernetes Engine (GKE) and enforces security policies at deploy time. Binary Authorization works with container images from Container Registry or another container image registry.

With Binary Authorization, you can automatically and digitally 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:

  • Container Registry or another registry that stores the container images you want to deploy
  • GKE, which runs the images in a cluster
  • Container Analysis, which stores trusted metadata used in the authorization process
  • Binary Authorization itself, which allows or blocks deployment of images to GKE based on a policy you configure

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


GKE allows teams to develop highly decoupled systems - for example, those built on microservices architectures - and encourages the use of short-lifecycle processes around continuous integration (CI) and continuous deployment (CD). In such environments, software often moves from deployment cluster to deployment cluster during staging and tests, making it difficult to ensure that all software is built, tested, released, and deployed according to internal best practices and standards.

Binary Authorization aims to reduce the risk of deploying wrong, faulty, or unauthorized software in this type of environment. Using this service, you can explicitly specify which internal processes must complete before a container image enters each deployment stage and then check to make sure that authorized parties have verified process completion.

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 verifies that the container image was built by a specific build system or continuous integration (CI) pipeline.
  • Vulnerability scanning, where the CI-built container image has also been scanned by Container Analysis and identified vulnerabilities were resolved before the CI pipeline itself or an individual created the attestation.
  • Manual check, where a representative, QA for example, manually creates the attestation.

See Getting started with the 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 specify the criteria that an image must pass before it can be deployed. A typical policy requires a container image to have a verified digital signature before it is deployed.

In this type of policy, a rule specifies which trusted authorities, called signers, must assert that required processes have completed and that an image is ready to move to the next stage of deployment. A signer can be a human user or, more often, a machine process like a build and test system or a part of your continuous deployment pipeline.

During the development lifecycle, signers digitally sign globally unique container image descriptors, thereby creating certificated statements called attestations. Later, during the deploy phase, Binary Authorization uses attestors to verify the certificate indicating that required processes in your pipeline have been completed.

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


To set up Binary Authorization, you must first enable the service for the projects that take part in your deployment and authorization pipeline. Then you create GKE clusters, as required, with the service enabled.

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 which 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 securely 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.

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.