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. It enables you to configure a policy that the service enforces when an attempt is made to deploy a container image on one of the supported container-based platforms.
Binary Authorization supports the following platforms:
- Google Kubernetes Engine (GKE): runs images in clusters that are hosted on Google Cloud.
- Cloud Run (Preview): runs containerized applications on a fully managed serverless platform.
- Anthos Service Mesh (Preview): manages a reliable service mesh on-premises or on Google Cloud.
- Anthos clusters on VMware: runs the images in clusters that are hosted in on-premises data centers.
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.
- Container Analysis provides vulnerability information that you can use with Binary Authorization to control deployment. Separately, Container 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.
- Google 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 itself, which allows or blocks deployment of images based on the policy you configure.
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:
- 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
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 Container Analysis. In this case, the attestation is only created if identified vulnerabilities satisfy a vulnerability signing policy.
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
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:
- Set up Binary Authorization on GKE
- Set up Binary Authorization on Anthos clusters on VMware (Preview)
- Set up Binary Authorization on Cloud Run (Preview)
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:
- View audit logs (GKE)
- View audit logs (Cloud Run) (Preview)
- View audit logs (Anthos clusters on VMware) (Preview)
For more information on deployment, see the following guides:
- Deploy containers (GKE)
- Deploy containers (Anthos clusters on VMware example) (Preview)
- Use Binary Authorization with Cloud Run (Preview)
Continuous Validation (CV) is a feature of Binary Authorization that periodically checks container images associated with running Pods for continued policy conformance.
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.
- For complete, end-to-end tutorials, see the following:
- Configure a Binary Authorization policy for Anthos Service Mesh (Preview) by using the console or the command-line tool.