Binary Authorization Study Notes

Binary Authorization is a deploy-time security control for GKE and related runtimes that ensures only trusted, verified container images are allowed to deploy. Images must be signed by trusted authorities, called attestors, who vouch for checks such as passing a build or vulnerability scan. A central policy decides which attestations each cluster or project requires before an image can run.

Key facts

• An attestor is a trusted authority, backed by a cryptographic key pair, that signs an attestation confirming an image passed a specific check, such as a successful build or a clean vulnerability scan.
• Attestations are bound to an image's digest, not its tag, so changing the image content invalidates the attestation even if the tag name stays the same.
• Policies are enforced at deploy time: when Kubernetes tries to create pods, Binary Authorization checks the image against the policy and blocks deployments that lack required attestations.
• Policy rules can be set at the project or cluster level, with a default rule and specific rules for images, and modes include requiring attestations or allowing images from specified path patterns.
• A break-glass mechanism lets an authorized user override enforcement during an emergency deployment, and that override is logged for later audit review.
• Binary Authorization integrates with Cloud Build, which can be configured to sign images it builds, and with Artifact Analysis, which stores attestation and vulnerability metadata.
• Dry-run mode logs what would have been blocked without actually preventing deployment, which lets teams test a new policy safely before turning on enforcement.
• The service focuses on software supply chain security: it answers whether an image was built and verified by approved processes, complementing runtime security controls inside the cluster.

What the exam expects you to know

• Identifying Binary Authorization as the control that blocks unsigned or unverified images at deployment time on GKE.
• Explaining attestors and attestations and why signing is tied to the image digest rather than a mutable tag.
• Using dry-run mode first when introducing a policy, so violations are visible in logs before production deployments start failing.
• Knowing break-glass exists for emergencies but creates an audited exception, not a normal deployment path.
• Connecting Cloud Build as the signer in a pipeline where images are attested after build and scan steps succeed.
• Distinguishing deploy-time admission control from vulnerability scanning itself: scanning finds issues, Binary Authorization enforces the decision.

Binary Authorization vs Artifact Registry vulnerability scanning: when to use which

Artifact Registry with Artifact Analysis scanning tells you what is inside an image and which known vulnerabilities it contains, but it does not by itself stop a vulnerable or unsigned image from deploying. Binary Authorization enforces policy at deploy time by checking for required attestations, which may include a scanning attestation. Choose scanning when the need is visibility and reporting; choose Binary Authorization when the requirement is a hard gate that only verified images can run in your clusters. In mature pipelines the two work together, with scan results feeding an attestor. See also the Artifact Registry vulnerability scanning notes.

Useful gcloud commands

gcloud container binauthz policy export
gcloud container binauthz attestors list
gcloud container binauthz policy import policy.yaml

Common exam traps

• Assuming a signed tag is enough: attestations apply to the digest, so rebuilding or retagging an image requires the correct attestation for that exact digest.
• Turning on enforcement without dry-run testing and then blocking legitimate deployments that never went through the signing pipeline.
• Treating break-glass as routine: every break-glass deployment bypasses policy and is logged, so repeated use signals a broken process, not a convenience feature.
• Believing Binary Authorization scans images itself: it checks attestations; separate tools such as Artifact Analysis perform the scanning that an attestor may rely on.

Frequently asked questions

What is an attestor in Binary Authorization?

An attestor is a named authority that uses a private key to sign statements, called attestations, about a container image digest. Each attestor represents one verification step, such as a completed build or a passed vulnerability scan. Policies name the attestors whose signatures an image must carry before it is allowed to deploy.

What happens when an image fails the policy?

In enforcement mode the deployment is blocked and the pod is not created, and the denial is recorded in audit logs with the reason. In dry-run mode the deployment proceeds but the policy violation is logged, which is useful while you are tuning the policy. Either way, the event is visible rather than silent.

When should break-glass be used?

Break-glass is reserved for genuine emergencies, such as deploying an urgent fix when the normal attestation pipeline is unavailable. An authorized user annotates the deployment to bypass Binary Authorization, the bypass is logged for audit, and the team should restore the normal signed path as soon as the incident is resolved.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.