Professional Cloud Developer
Professional Cloud Developer
Intermediate
Gauge your current knowledge
Intermediate
Gauge your current knowledge
Securing application artifacts using Binary Authorization
...
Professional Cloud Developer
Gauge your current knowledge
Gauge your current knowledge
Binary Authorization is a security service in Google Cloud that checks container images at deploy time before they run in environments like Google Kubernetes Engine (GKE) or Cloud Run. The core of the system is a policy — a set of rules that decides whether a particular image is allowed to deploy. By setting up these policies, teams can protect their software supply chain and stop untrusted or unauthorized images from reaching production.
Every policy uses an Evaluation Mode to decide how to handle a deployment request. There are three modes:
This flexibility lets teams choose the right level of security for each environment, from development to production.
The Enforcement Mode determines what happens when an image fails the policy rules. In Block and Audit Log mode, the system refuses to deploy the image and records the event in the logs. This is the standard choice for production because it stops non-compliant images. In Dry Run: Audit Log Only mode, the image is allowed to deploy even if it violates the policy, which is useful for testing new rules without breaking existing workflows.
Policies are built with a Default Rule that applies to the entire project. You can also add Specific Rules for individual clusters, namespaces, or service accounts. These specific rules override the default rule, so teams can apply different security requirements to different parts of a large organization. To keep the system stable, the policy includes Exempt Images — predefined registry paths (such as Google-maintained system images) that are always allowed to deploy. For emergencies, the Breakglass feature lets administrators temporarily bypass the policy and deploy a critical fix, and every use of breakglass is recorded in the audit logs for later review.
Binary Authorization works closely with Artifact Analysis, a service that stores metadata about container images, such as build details and vulnerability scan results. Together, they form a gatekeeper that checks images for security flaws before they are deployed. You can create a policy that requires an image to be scanned and verified before it can run in production. This integration prevents unauthorized or risky software from being used by ensuring every image has a digital signature (an attestation) proving it passed all security checks.
A policy in this context defines rules that often require attestors — trusted authorities that verify that a specific process (like a manual QA check or an automated security scan) was completed. Key components include:
In urgent situations, a team may need to deploy a fix immediately, even if it hasn’t finished the standard authorization process. The breakglass feature allows users to bypass policy enforcement during an emergency. This is a temporary measure meant only for critical fixes that cannot wait. Even when breakglass is used, every action is recorded. Cloud Audit Logs track when a deployment is blocked or when someone uses breakglass, giving full visibility into who did what and why. Additionally, Continuous Validation can monitor running containers after deployment to ensure they stay compliant with your security policies.
At the heart of Binary Authorization is the attestor, a verification authority that confirms an image has passed specific security requirements. Establishing attestors is a critical step in creating a secure software supply chain. Attestors can represent manual approvals from security teams or automated checks from a build system. They act as gatekeepers for your production environment.
To ensure the integrity of approvals, Binary Authorization uses cryptographic verification with digital signatures. A signer uses a private key to create an attestation — a digital signature linked to a specific container image digest. The corresponding public key is stored in the attestor so the system can verify the signature at deploy time. Using Cloud Key Management Service (KMS) is the recommended way to manage these keys because it provides a secure, centralized platform for handling sensitive cryptographic material.
The process involves several key components:
Storing these records correctly allows the Binary Authorization enforcer to quickly check if an image is authorized.
A Binary Authorization policy defines the rules for which images are allowed to run in your cluster. You can configure policies to require attestations from one or more specific attestors before a deployment is successful. This ensures that images satisfy organizational security requirements, such as passing a vulnerability scan or a quality assurance test. Enforcing these policies prevents unauthorized or potentially harmful software from entering your cloud-native applications.
In a professional environment, organizations often use a multi-project configuration to maintain a clear separation of duties. This setup involves different projects for the GKE clusters, the attestor management, and the storage of attestation data. Granting the correct IAM roles to service agents across these projects is essential for the system to function. This structure ensures that no single person or process has total control over the entire deployment pipeline.