1096: Binary Authorization

1. Overview

Binary Authorization is a security pattern that enforces software supply chain security for containerized applications. It ensures that only trusted and verified container images are deployed into production environments. The core problem this pattern solves is the risk of deploying unauthorized, vulnerable, or malicious code, which can have devastating consequences for an organization’s security and reputation. By requiring cryptographic attestations at each stage of the software development lifecycle, Binary Authorization provides a robust gatekeeping mechanism that prevents unvetted code from reaching production.

The historical context of Binary Authorization is rooted in Google’s internal security practices, where it was developed to secure the company’s massive-scale containerized infrastructure. As container adoption grew across the industry, the need for similar security controls became apparent. Google then open-sourced the underlying concepts in projects like Grafeas and Kritis and offered Binary Authorization as a managed service on Google Cloud. This pattern is crucial for organizations because it provides a concrete way to implement a “shift-left” security posture, integrating security into the development process rather than treating it as an afterthought. For the commons, it promotes a culture of security and trust, enabling developers to build and deploy applications with greater confidence.

2. Core Principles

1. Trust, but Verify: This principle dictates that no container image should be trusted by default. Every image must be verified against a set of predefined policies before it can be deployed. This moves away from a perimeter-based security model to a zero-trust approach.

2. Policy as Code: Deployment policies should be defined as code and managed in a version control system. This ensures that policies are consistent, auditable, and can be updated in a controlled manner. It also enables automation and integration with CI/CD pipelines.

3. Separation of Concerns: Different teams and individuals have distinct roles and responsibilities in the software supply chain. Binary Authorization allows for a clear separation of concerns, where developers, QA engineers, and security teams can each provide their own attestations at different stages of the lifecycle.

4. Immutable Infrastructure: Once a container image is built and attested, it should be considered immutable. Any changes to the image should require a new build and a new set of attestations. This prevents unauthorized modifications and ensures the integrity of the deployed application.

5. Defense in Depth: Binary Authorization is not a silver bullet. It should be used as part of a comprehensive, multi-layered security strategy that includes vulnerability scanning, network security, and runtime monitoring.

3. Key Practices

1. Define a Clear and Granular Policy: Start by defining a clear and granular deployment policy that specifies the required attestations for different environments (e.g., development, staging, production). The policy should be as specific as possible to avoid ambiguity.

2. Use a Central, Trusted Image Registry: Store all container images in a central, trusted registry that provides features like access control, vulnerability scanning, and image signing. This ensures that only authorized users can push and pull images.

3. Integrate with CI/CD Pipelines: Automate the attestation process by integrating it into your CI/CD pipelines. This ensures that attestations are generated automatically as code moves through the development lifecycle.

4. Use Cryptographic Signing: Use digital signatures to ensure the integrity and authenticity of attestations. This prevents tampering and ensures that attestations can be trusted.

5. Monitor for Policy Violations: Continuously monitor for policy violations and alert the appropriate teams when a non-compliant deployment is blocked. This provides visibility into the security of your software supply chain.

6. Start with a Permissive Policy: When first implementing Binary Authorization, start with a permissive policy that logs policy violations but does not block deployments. This allows you to identify and fix issues without disrupting development workflows. Gradually tighten the policy as you gain confidence in the system.

7. Regularly Audit and Update Policies: Regularly audit your deployment policies to ensure they are still effective and up-to-date with the latest security best practices. As your organization’s security needs evolve, so should your policies.

4. Implementation

Implementing Binary Authorization typically involves a phased approach. The first step is to enable the Binary Authorization service for your container environment, such as Google Kubernetes Engine (GKE) or Cloud Run. Once enabled, you can define a deployment policy that specifies the rules for deploying container images. This policy can be as simple as requiring a single attestation from a trusted authority or as complex as requiring multiple attestations from different teams.

Next, you need to set up attestors, which are entities that can create attestations. An attestor can be a person, such as a QA engineer who manually verifies a build, or an automated system, such as a CI/CD pipeline that runs a suite of tests. Each attestor has a cryptographic key pair that is used to sign attestations. The public key is registered with Binary Authorization, while the private key is used to sign the attestations. When a deployment is attempted, Binary Authorization verifies the signature on the attestation using the public key of the attestor.

Key considerations for a successful implementation include robust key management practices to protect the private keys of attestors, a phased rollout to minimize disruption, and comprehensive training for developers and operations teams. Common tools used for implementing Binary Authorization include Google Cloud Build for automated builds and attestations, Jenkins for CI/CD orchestration, and open-source tools like in-toto for defining and verifying the integrity of the software supply chain. Success can be measured by the number of non-compliant deployments blocked, the reduction in security incidents related to unauthorized code, and the overall improvement in the organization’s security posture.

5. 7 Pillars Assessment

6. When to Use

• In regulated industries: For organizations in regulated industries like finance, healthcare, and government, where compliance with strict security standards is mandatory.
• For mission-critical applications: For applications that are critical to the business and where a security breach could have a significant impact.
• In large, complex organizations: For large organizations with multiple development teams and complex software supply chains, where it is difficult to maintain visibility and control over the deployment process.
• As part of a zero-trust security model: For organizations that are adopting a zero-trust security model, where no user or system is trusted by default.
• To prevent insider threats: To mitigate the risk of insider threats, where a malicious actor with access to the development environment could inject malicious code into the application.

7. Anti-Patterns & Gotchas

• Overly complex policies: Creating policies that are too complex and difficult to manage can lead to confusion and errors.
• Lack of automation: Manually creating and verifying attestations is time-consuming and error-prone. It is essential to automate the attestation process as much as possible.
• Poor key management: Failing to properly secure the private keys of attestors can compromise the entire system.
• Ignoring policy violations: Failing to monitor for and act on policy violations defeats the purpose of the pattern.
• “Big bang” implementation: Attempting to implement Binary Authorization across the entire organization at once is likely to fail. A phased rollout is a much more effective approach.
• Not involving developers: Failing to involve developers in the design and implementation of the system can lead to resistance and adoption challenges.

8. References

1. [Binary Authorization overview

   Google Cloud](https://docs.cloud.google.com/binary-authorization/docs/overview)

2. Grafeas
3. Kritis
4. in-toto
5. What is Binary Authorization and How to Implement it?