Overview

This page contains an overview of Binary Authorization.

Introduction

Binary Authorization is a service on Google Cloud Platform (GCP) that provides software supply-chain security for applications that run in the Cloud. Binary Authorization works with images that you deploy to Google Kubernetes Engine (GKE) from Container Registry or another container image registry.

With Binary Authorization, you can ensure that internal processes that safeguard the quality and integrity of your software have successfully completed 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.

Background

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 deployment (CD), where software moves from deployment cluster to deployment cluster during staging and tests. In such environments, it can be 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.

Lifecycle

A deployment lifecycle for container images might 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 test, 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.

Features

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.

Typically, a rule specifies which trusted authorities or attestors must assert that required processes have completed and that an image is ready to move to the next stage of deployment. An attestor 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, attestors make statements called attestations that verify that required processes in your pipeline have been completed.

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

Setup

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 who can assert that an image is ready to move on to the next stage. The authority of an attestor is secured by a cryptographic key pair, where the public key is uploaded to Binary Authorization.

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

Authorization

Before a container image can be deployed, any required attestors 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 attestor's private key.

For more information on authorization, see Creating Attestations.

Enforcement

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.

Was this page helpful? Let us know how we did:

Send feedback about...

Binary Authorization Documentation