Deploy only what you trust: introducing Binary Authorization for Google Kubernetes Engine

“How do I trust what is running on my production infrastructure?” is one of the top questions we hear from those working in enterprise security and DevOps. To help you answer that question, we’re excited to introduce Binary Authorization in beta so you can be more confident that only trusted workloads are deployed to Google Kubernetes Engine. Integrated into the Kubernetes Engine deployment API, Binary Authorization is a container security feature that provides a policy enforcement chokepoint to ensure only signed and authorized images are deployed in your environment.

This capability is especially useful in this era of containerized microservices, as companies often run hundreds to thousands of jobs in production, many of them accessing sensitive and valuable data. Identity-based deployment control (i.e., restricting who can deploy) relies on human operational knowledge and trust that cannot scale to meet the needs of enterprises with automated build and release infrastructure, where deployments may happen hundreds of times a day across dozens of teams.

Containerized workloads discourage direct modification to running software—instead, using continuous integration/continuous deployment (CI/CD), changes are applied to whole containers. This allows users to define streamlined tests and validations to ensure only trusted code are deployed. But even this approach relies on identity-based deployment control today. An insider could still bypass the CI/CD controls and either maliciously or accidentally deploy untrusted code. For example, a developer could accidentally deploy a test binary to production or someone in a hurry could bypass testing and integration verification—not to mention a malicious injection of cryptocurrency mining software in the build.

Binary Authorization follows these principles:

• Establish a preventative security posture by only running trusted code

• Simplify governance with a single structured path for code to get from development to production

• Use open source to keep CI/CD tools pluggable and interoperable.

Binary Authorization is based on internal Google technology we’ve used to protect our production deployments for almost a decade.

Let’s go through the core features of Binary Authorization and how it works to secure your software supply chain.

Signature verification for pod creation

Binary Authorization formalizes and codifies an organization's deployment requirements by integrating with the desired CI/CD stages to produce signatures, or “attestations,” as an image passes through. Binary Authorization acts as an admission controller by preventing images that do not meet these criteria from being deployed. In Kubernetes Engine, this is implemented with the pod creation API, using the ImagePolicy admission controller. The signatures on the image (image attestations) are verified against the Container Analysis API. Similarly, if you wanted to implement this yourself, you could use the open-source project Grafeas to create your own policies, and allow or block pod creation based on your requirements.

Binary Authorization also integrates with Cloud Audit Logging to record failed pod creation attempts for later review.

Image and repository whitelisting

In addition to signature-based verification, Binary Authorization policy also supports whitelisting images using name patterns. A user can specify a repository, a path or particular set of images that are allowed to deploy. This is a good option to get a quick start with restricting production deployment, and it is also a powerful tool to control third-party images that do not follow the internal workflows. 

A common source of production vulnerability is unpatched third-party software. These images are not built in-house, so they don’t have the necessary attestations from a trusted CI/CD process. With Binary Authorization whitelisting, you can have a centralized whitelist of all the third-party images and easily identify, locate and update when a third-party image becomes outdated or vulnerable.

Breakglass deployment

Production deployment processes can get messy. Not all deployments abide by the required build-and-release process at all times—especially not in the case of an emergency fix. Binary Authorization accommodates these operational anomalies with its “breakglass” deployment feature.

You can specify the breakglass flag as an annotation in the deployment, which allows pod creation even if the images violate policy. Audit logs for the deployment will contain the breakglass annotation, so your incident response team can still review these deployments.

Open source support

As part of the Binary Authorization beta launch, we have updated Kritis, an open source implementation of deployment-time enforcement. Just like Binary Authorization, Kritis uses an admission controller to enforce pod creation policies for any Kubernetes deployment.

Kritis integrates with Grafeas, the open source metadata server. This way, you can use Container Registry Container Analysis API and Binary Authorization for your Google Kubernetes Engine deployments, and have consistency in your environment with similar enforcement flows on-prem using the open source building blocks.

We’d like to invite customers and partners to contribute to the Kritis community and enable deployment policy enforcement for a wide range of Kubernetes deployments. For more information , check out the Kritis website and tutorial, plus join the conversation in the discussion group.

Integration with CI/CD tools

Binary Authorization uses standard encrypted PGP signatures for enforcement, which makes it easy for users to integrate it with existing CI/CD tool chains to enable deployment enforcement based on build, test and vulnerability findings as well as manual assertions.

In addition to custom integration, Binary Authorization beta works out of the box with a number of CI/CD and security tools, created by us and by partners.

• Container Registry vulnerability scanning checks for known vulnerabilities in container images stored in Google Container Registry. With Binary Authorization integration, users can gate deployments based on vulnerability findings. Follow these detailed instructions to set this up.

• Google Cloud Build lets you build containers quickly on GCP. It generates verifiable records for every build. Users can gate deployments using build record details to ensure that only images built from trusted sources can be deployed in your environment. See integration details.

• Twistlock's container security platform offers container image analysis and vulnerability scanning, among other features. With Binary Authorization integration, users can define policies in Twistlock on what is allowed to deploy based on the scan results and have it enforced at the Kubernetes Engine layer. See instruction video.

• CloudBees offers enterprise grade CI/CD solutions powered by Jenkins. Users can build end-to-end CI/CD pipelines and attach attestations across all stages and all teams involved in the software delivery chain. All attestations defined must be present upon deployment for that pipeline to comply with defined policies and reach production. See how to configure Binary Authorization using CloudBees Core.

• Shopify, the leading multi-channel commerce platform that powers over 600,000 businesses in approximately 175 countries, is an early adopter of Binary Authorization. They’ve developed and open sourced Voucher, a tool that creates attestations for Binary Authorization and prevents the deployment of images that don’t meet Shopify’s security requirements. Voucher enforces requirements like “Does an image run as a root?” or “Does it contain vulnerable software?“ Check out the open source project here.

• HashiCorp Terraform is an open source tool for infrastructure as code. Users can configure Binary Authorization through Terraform and enable deploy policy enforcement as part of the infrastructure setup. We are working on Terraform support for Binary Authorization; stay tuned.

Getting started with Binary Authorization

With this beta release of the Binary Authorization API, you can create Kubernetes Engine clusters with Binary Authorization enabled to give you deploy-time policy controls.

You can create attestors with custom-managed signing keys. An attestor represents an authority that can verify or attest to one aspect of an image (e.g., a “builder attestor” can attest that an image has been built by the trusted builder).

You can define deployment policy at both project and cluster level for different control granularities (e.g., you may want to apply different deployment policies for your dev and compliance clusters). Policy is defined in terms of attestors, so, for example, in order for an image to be allowed to deploy to the production cluster, it needs to have attestations from both the builder and QA attestors.

You can whitelist trusted images by digest. This is especially applicable to third-party images that do not go through your build pipeline and don’t have all the required attestations.

Once you have all the policies set up, you can deploy to Kubernetes Engine as usual. Any policy violations or breakglass deployments would be recorded in the Cloud Audit Log, viewable in Stackdriver.

For step-by-step tutorials on Binary Authorization, check out our Getting Started Guide and Google Developers Codelab. You can also learn more by watching this screencast, our NEXT presentation and join the Binary Authorization discussion group. We’re looking forward to seeing how you use this beta feature.