{"id":795,"date":"2026-04-16T04:37:40","date_gmt":"2026-04-16T04:37:40","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-binary-authorization-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security\/"},"modified":"2026-04-16T04:37:40","modified_gmt":"2026-04-16T04:37:40","slug":"google-cloud-binary-authorization-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-binary-authorization-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security\/","title":{"rendered":"Google Cloud Binary Authorization Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Binary Authorization is a Google Cloud <strong>Security<\/strong> service that helps you control <strong>which container images are allowed to run<\/strong> in your environments. It acts like a \u201cdeploy-time gate\u201d that checks whether an image meets your organization\u2019s trust requirements (for example, \u201cmust be built by our CI,\u201d \u201cmust be signed,\u201d \u201cmust be approved by security\u201d) before it can be deployed.<\/p>\n\n\n\n<p>In simple terms: <strong>Binary Authorization blocks untrusted container images from being deployed<\/strong>. Instead of relying only on human process (reviews, tickets, approvals), you can enforce an automated policy: <em>if the image is not properly attested, it can\u2019t run<\/em>.<\/p>\n\n\n\n<p>Technically, Binary Authorization integrates with deployment targets (most commonly <strong>Google Kubernetes Engine (GKE)<\/strong>; also available for some other Google Cloud runtimes\u2014verify current coverage in official docs) and uses <strong>attestors<\/strong> (verifiers) and <strong>attestations<\/strong> (cryptographically verifiable approvals) stored in <strong>Container Analysis<\/strong>. At deployment time, the platform evaluates a <strong>Binary Authorization policy<\/strong> against the image\u2019s digest and required attestations; if requirements aren\u2019t met, the deployment is denied and logged.<\/p>\n\n\n\n<p>The problem it solves: in container-based delivery, it\u2019s easy for an unreviewed image (wrong tag, compromised registry, manual push, shadow pipeline, \u201clatest\u201d drift) to reach production. Binary Authorization gives platform\/security teams a <strong>central enforcement point<\/strong> to reduce supply-chain risk and improve compliance.<\/p>\n\n\n\n<blockquote>\n<p>Service status and naming: <strong>Binary Authorization<\/strong> is the current official Google Cloud product name (not retired). Always verify the latest features and supported targets in the official documentation: https:\/\/cloud.google.com\/binary-authorization\/docs<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Binary Authorization?<\/h2>\n\n\n\n<p>Binary Authorization is a Google Cloud <strong>policy enforcement service<\/strong> that helps ensure only <strong>trusted, verified container images<\/strong> are deployed to supported runtimes (most notably GKE).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>To <strong>validate and enforce<\/strong> that container images meet defined security and provenance requirements <strong>before deployment<\/strong>, using policy and cryptographically verifiable attestations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define <strong>policies<\/strong> that describe what images are allowed and what <strong>attestations<\/strong> are required.<\/li>\n<li>Create <strong>attestors<\/strong> that represent trusted authorities (CI system, security team, compliance checks).<\/li>\n<li>Create <strong>attestations<\/strong> (signed approvals) for specific image digests.<\/li>\n<li>Enforce policy at deploy time with <strong>auditability<\/strong> (denials and decisions logged).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual model)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Component<\/th>\n<th>What it is<\/th>\n<th>Why it matters<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Binary Authorization Policy<\/td>\n<td>Rules describing which images require which attestations, plus enforcement mode<\/td>\n<td>Central control point; prevents \u201canything can deploy\u201d<\/td>\n<\/tr>\n<tr>\n<td>Attestor<\/td>\n<td>A trusted authority definition (with public keys) that can verify attestations<\/td>\n<td>Lets you model multiple approvals (CI + security)<\/td>\n<\/tr>\n<tr>\n<td>Attestation<\/td>\n<td>A signed statement approving a specific image digest<\/td>\n<td>Creates an immutable, verifiable approval trail<\/td>\n<\/tr>\n<tr>\n<td>Container Analysis (Grafeas)<\/td>\n<td>Stores attestation metadata as occurrences\/notes<\/td>\n<td>System of record for attestations and metadata<\/td>\n<\/tr>\n<tr>\n<td>Cloud KMS (optional but common)<\/td>\n<td>Manages signing keys (private keys) used by CI\/security<\/td>\n<td>Strong key management, rotation, IAM control<\/td>\n<\/tr>\n<tr>\n<td>Deployment target integration (e.g., GKE)<\/td>\n<td>Admission-time enforcement of the policy<\/td>\n<td>Blocks untrusted images before they run<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed control-plane security service<\/strong> (policy + verification), integrated with other Google Cloud services.<\/li>\n<li>It is not a container registry and not a vulnerability scanner (though it can be integrated with scanning workflows).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (project\/region)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Policies and attestors are project-scoped resources<\/strong> (managed in a Google Cloud project).<\/li>\n<li>Enforcement happens in the target runtime (for example, a GKE cluster), which may be regional\/zonal. The policy is still managed at the project level.<\/li>\n<li>Container Analysis storage for attestations is associated with projects.<\/li>\n<\/ul>\n\n\n\n<p>Always confirm any org-level or fleet-level capabilities in the latest docs if you manage multiple projects centrally.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Binary Authorization commonly sits in a supply-chain pipeline like this:\n&#8211; <strong>Artifact Registry<\/strong> stores images.\n&#8211; <strong>Cloud Build \/ CI<\/strong> builds images and can create attestations.\n&#8211; <strong>Container Analysis<\/strong> stores metadata and attestations.\n&#8211; <strong>Cloud KMS<\/strong> protects signing keys.\n&#8211; <strong>GKE<\/strong> enforces policy during deploy admission.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Binary Authorization?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduce the risk of deploying compromised or unapproved software (supply-chain security).<\/li>\n<li>Standardize release governance across teams and environments.<\/li>\n<li>Support audit needs by proving \u201conly approved artifacts reached production.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce deployments by <strong>digest<\/strong>, not mutable tags like <code>latest<\/code>.<\/li>\n<li>Require signatures\/attestations from trusted systems.<\/li>\n<li>Prevent \u201cmanual pushes\u201d or shadow pipelines from shipping to prod.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Central policy reduces per-team variance.<\/li>\n<li>Audit logs provide quick forensics: who tried to deploy what, and why it was blocked.<\/li>\n<li>Enables safe \u201cbreak-glass\u201d patterns (with tight IAM controls) when needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Helps implement controls aligned with secure software supply chain practices (SLSA-like goals, internal compliance gates).<\/li>\n<li>Enforces separation of duties: CI attests build provenance; security attests scanning\/approval.<\/li>\n<li>Encourages consistent artifact promotion strategy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Policies scale across clusters\/environments with consistent rules.<\/li>\n<li>Automated enforcement reduces manual review bottlenecks as deployments increase.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Binary Authorization when:\n&#8211; You deploy containers to GKE (or another supported Google Cloud runtime) and need <strong>hard enforcement<\/strong>.\n&#8211; You want cryptographically verifiable approvals, not just \u201clabels\u201d or CI checks.\n&#8211; You need a practical control to reduce supply-chain attack surface.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Binary Authorization may not be the right fit if:\n&#8211; You don\u2019t use container runtimes it supports (verify supported targets).\n&#8211; Your organization is not ready to manage image digests, promotion, and signing keys.\n&#8211; You need deep in-cluster policy beyond image trust (you might need OPA\/Gatekeeper\/Policy Controller, Kyverno, etc. alongside or instead).<\/p>\n\n\n\n<p>Binary Authorization is often best <strong>in combination<\/strong> with Kubernetes policy, vulnerability scanning, and CI\/CD controls.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Binary Authorization used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Finance and fintech (strict change control, audit trails)<\/li>\n<li>Healthcare and life sciences (regulated workloads)<\/li>\n<li>Retail and e-commerce (large-scale continuous delivery with governance)<\/li>\n<li>SaaS and technology (supply chain and tenant isolation concerns)<\/li>\n<li>Government and public sector (compliance and provenance)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building internal developer platforms (IDPs)<\/li>\n<li>DevSecOps and security engineering teams enforcing release controls<\/li>\n<li>SRE teams improving operational safety for production clusters<\/li>\n<li>Compliance and risk teams requiring provable controls<\/li>\n<li>Application teams consuming a governed deployment platform<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices on GKE<\/li>\n<li>Batch jobs \/ worker pools<\/li>\n<li>Internal APIs and customer-facing services<\/li>\n<li>Multi-tenant clusters where strict release control matters<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-environment pipelines (dev \u2192 staging \u2192 prod)<\/li>\n<li>Multi-project landing zones (separate projects for envs\/teams)<\/li>\n<li>Shared platform clusters with multiple namespaces\/teams (with careful policy design)<\/li>\n<li>GitOps-based delivery (where the deploy action is automated, but still must be gated)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: use <strong>dry-run<\/strong> or environment-specific rules to avoid blocking iteration while you validate policy behavior.<\/li>\n<li><strong>Production<\/strong>: enforce strict rules (block-and-log), require attestations from CI and security, and restrict break-glass controls.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic use cases where Binary Authorization fits well.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Enforce \u201conly CI-built images can run\u201d<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Developers can push images manually, bypassing CI controls.<\/li>\n<li><strong>Why it fits:<\/strong> Require a CI attestor signature for any deployable image.<\/li>\n<li><strong>Scenario:<\/strong> Only Cloud Build (or your CI SA) can attest images; production clusters require that attestation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Block images that aren\u2019t pinned by digest<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Tags like <code>latest<\/code> or <code>release<\/code> can be changed after approval.<\/li>\n<li><strong>Why it fits:<\/strong> Attestations are created for <strong>immutable digests<\/strong>; policy evaluation is digest-based.<\/li>\n<li><strong>Scenario:<\/strong> Deployment manifests must reference <code>image@sha256:...<\/code>; otherwise the image won\u2019t match attestations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Separate duties: CI attests build, Security attests approval<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> One team controls everything; audit wants separation of duties.<\/li>\n<li><strong>Why it fits:<\/strong> Policies can require <strong>multiple attestations<\/strong> (CI + Security).<\/li>\n<li><strong>Scenario:<\/strong> CI attests after build and tests; security team attests after review and scan sign-off.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Ensure images come only from your Artifact Registry<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams pull random public images or from unknown registries.<\/li>\n<li><strong>Why it fits:<\/strong> Use policy rules and allowlists to restrict acceptable image patterns (and require attestations for your registry path).<\/li>\n<li><strong>Scenario:<\/strong> Only <code>REGION-docker.pkg.dev\/PROJECT\/REPO\/*<\/code> is accepted for production workloads.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Promote artifacts across environments with controlled approvals<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> \u201cRebuild in prod\u201d breaks traceability and reproducibility.<\/li>\n<li><strong>Why it fits:<\/strong> Same digest can be promoted; new attestation indicates approval for higher environment.<\/li>\n<li><strong>Scenario:<\/strong> Staging requires CI attestation; prod requires CI + release-manager attestation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Prevent compromised registry credentials from becoming production incidents<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> If registry push creds are compromised, attacker can publish a malicious image.<\/li>\n<li><strong>Why it fits:<\/strong> Without the required attestations, the image will be blocked at deploy time.<\/li>\n<li><strong>Scenario:<\/strong> Attacker pushes <code>payments:1.2.3<\/code> but can\u2019t forge security attestation; deployment fails.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Enforce policy across multiple clusters consistently<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Different clusters drift in security posture.<\/li>\n<li><strong>Why it fits:<\/strong> Central project-level policy can apply consistently to clusters using it.<\/li>\n<li><strong>Scenario:<\/strong> All prod clusters in a project enforce the same Binary Authorization policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Integrate with GitOps so \u201cmerge = deploy\u201d still has a guardrail<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> GitOps applies manifests automatically; a bad image reference could deploy instantly.<\/li>\n<li><strong>Why it fits:<\/strong> Admission-time enforcement is independent of the GitOps tool.<\/li>\n<li><strong>Scenario:<\/strong> Argo CD syncs a new deployment; GKE denies it because image lacks required attestation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Build an auditable approval trail for compliance<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Auditors want evidence that only approved software runs in production.<\/li>\n<li><strong>Why it fits:<\/strong> Attestations plus audit logs provide a verifiable trail.<\/li>\n<li><strong>Scenario:<\/strong> For each release digest, you show CI attestation + security attestation + deployment logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) \u201cBreak-glass\u201d controlled emergency deploys<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need to deploy a hotfix during an outage, but policy blocks it.<\/li>\n<li><strong>Why it fits:<\/strong> Temporary policy override is possible, but should be restricted by IAM and audited.<\/li>\n<li><strong>Scenario:<\/strong> On-call SRE has tightly scoped role to temporarily switch enforcement to dry-run, then re-enable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Multi-tenant platform: prevent one team from deploying risky images<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Shared clusters increase blast radius.<\/li>\n<li><strong>Why it fits:<\/strong> Central enforcement ensures baseline trust for all workloads.<\/li>\n<li><strong>Scenario:<\/strong> Platform team requires \u201capproved base image\u201d attestation for all tenants.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Enforce allowed base images (organizational standards)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams use inconsistent base images and patch levels.<\/li>\n<li><strong>Why it fits:<\/strong> Attest only images derived from approved base images (validated in CI) and enforce deployment.<\/li>\n<li><strong>Scenario:<\/strong> CI checks Dockerfile base image against approved list and attests only compliant digests.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on current, commonly used Binary Authorization capabilities. If you depend on a specific target runtime or advanced integration, verify in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Project-level policy enforcement (policy-driven admission)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines rules that determine whether an image can be deployed.<\/li>\n<li><strong>Why it matters:<\/strong> Consistent enforcement across deployments; prevents \u201cpolicy by documentation.\u201d<\/li>\n<li><strong>Practical benefit:<\/strong> Central governance with auditable decisions.<\/li>\n<li><strong>Caveats:<\/strong> Policy design must avoid blocking system\/managed images unintentionally; test with dry-run first.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Attestors (trusted authorities)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Represents an authority that can approve images; contains one or more public keys used to verify attestations.<\/li>\n<li><strong>Why it matters:<\/strong> Models real org approvals: CI, security, release manager.<\/li>\n<li><strong>Practical benefit:<\/strong> Multiple attestors allow separation of duties and staged approvals.<\/li>\n<li><strong>Caveats:<\/strong> Key management and attestor IAM must be carefully controlled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Attestations (signed approvals bound to image digests)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> A signed statement that a specific image digest is approved by an attestor.<\/li>\n<li><strong>Why it matters:<\/strong> Bind approvals to immutable artifacts (digests).<\/li>\n<li><strong>Practical benefit:<\/strong> Prevents tag drift and \u201capprove once, change later\u201d issues.<\/li>\n<li><strong>Caveats:<\/strong> Operationally requires digest-based workflows and a signing process.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Container Analysis (attestation storage and metadata)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Stores attestation notes\/occurrences (Grafeas model) that Binary Authorization evaluates.<\/li>\n<li><strong>Why it matters:<\/strong> Central system of record for artifact metadata.<\/li>\n<li><strong>Practical benefit:<\/strong> Integrates with other metadata\/scanning pipelines.<\/li>\n<li><strong>Caveats:<\/strong> You must ensure correct project scoping: where attestations are stored vs where enforcement occurs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Cloud KMS integration for signing keys (common approach)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you use Cloud KMS asymmetric signing keys to sign attestations.<\/li>\n<li><strong>Why it matters:<\/strong> Keys are protected, auditable, rotatable; access controlled by IAM.<\/li>\n<li><strong>Practical benefit:<\/strong> CI can sign without exporting private keys.<\/li>\n<li><strong>Caveats:<\/strong> KMS usage can introduce cost; key permissions must be least privilege.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Enforcement modes (block vs audit)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you control behavior: enforce (block) or audit-only (dry run).<\/li>\n<li><strong>Why it matters:<\/strong> Enables safe rollout and staged adoption.<\/li>\n<li><strong>Practical benefit:<\/strong> Start by logging policy violations, then switch to enforcement.<\/li>\n<li><strong>Caveats:<\/strong> Dry-run still allows risky deployments; keep it time-boxed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Allowlisting patterns (admission whitelist patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Exempts specific image patterns from enforcement (use sparingly).<\/li>\n<li><strong>Why it matters:<\/strong> Avoid blocking known trusted system images or transitional exceptions.<\/li>\n<li><strong>Practical benefit:<\/strong> Helps adoption without breaking essential workloads.<\/li>\n<li><strong>Caveats:<\/strong> Overuse can create security gaps; document and periodically review exceptions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Audit logging of decisions\/denials<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Writes logs for policy decisions, including denials.<\/li>\n<li><strong>Why it matters:<\/strong> Enables forensics, compliance evidence, and troubleshooting.<\/li>\n<li><strong>Practical benefit:<\/strong> Operators can quickly determine why a deploy failed.<\/li>\n<li><strong>Caveats:<\/strong> Log volume depends on deployment frequency; manage retention and filters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) IAM-based administration and separation of duties<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Controls who can change policy, manage attestors, and sign attestations.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents attackers or accidental changes from weakening controls.<\/li>\n<li><strong>Practical benefit:<\/strong> Aligns with compliance expectations.<\/li>\n<li><strong>Caveats:<\/strong> Misconfigured IAM is a common failure mode (either too permissive or breaks pipelines).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Works well with CI\/CD and GitOps pipelines<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Integrates into build\/sign\/promote workflows.<\/li>\n<li><strong>Why it matters:<\/strong> Enforcement is strongest when approvals are automated and consistent.<\/li>\n<li><strong>Practical benefit:<\/strong> Less manual work while improving security posture.<\/li>\n<li><strong>Caveats:<\/strong> Requires pipeline discipline: digests, metadata, promotion steps.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Binary Authorization sits between your deployment action and the runtime scheduler:\n1. A container image is built and stored in Artifact Registry (or another supported registry).\n2. A CI system (and optionally security tooling) creates <strong>attestations<\/strong> for the image digest.\n3. Attestations are stored in <strong>Container Analysis<\/strong>.\n4. When someone deploys to GKE, the admission control step evaluates:\n   &#8211; the Binary Authorization policy rules\n   &#8211; required attestations\n   &#8211; signature validity (public keys in attestors)\n5. If requirements are met, the deploy is admitted; otherwise it is denied and logged.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> Policy, attestors, and IAM define the \u201crules of trust.\u201d<\/li>\n<li><strong>Data plane:<\/strong> Container images flow through registries and clusters; attestations provide metadata binding to digests.<\/li>\n<li><strong>Decision point:<\/strong> Admission-time evaluation is the enforcement gate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services (common)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Kubernetes Engine (GKE):<\/strong> Enforces Binary Authorization at deploy time when enabled.<\/li>\n<li><strong>Artifact Registry:<\/strong> Primary image storage; digest-based deployments recommended.<\/li>\n<li><strong>Container Analysis:<\/strong> Stores attestations\/occurrences.<\/li>\n<li><strong>Cloud KMS:<\/strong> Stores signing keys and performs signing operations for attestations.<\/li>\n<li><strong>Cloud Build \/ CI:<\/strong> Builds images and can sign\/attest them as part of the pipeline.<\/li>\n<li><strong>Cloud Logging \/ Cloud Audit Logs:<\/strong> Captures policy decisions and admin changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Typical dependencies for a working setup:\n&#8211; <code>binaryauthorization.googleapis.com<\/code>\n&#8211; <code>containeranalysis.googleapis.com<\/code>\n&#8211; <code>cloudkms.googleapis.com<\/code>\n&#8211; <code>artifactregistry.googleapis.com<\/code>\n&#8211; <code>container.googleapis.com<\/code> (GKE)\n&#8211; <code>cloudbuild.googleapis.com<\/code> (if using Cloud Build)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong> governs:<\/li>\n<li>who can modify policies (<code>Policy Admin<\/code>-like roles)<\/li>\n<li>who can create\/manage attestors (<code>Attestors Admin<\/code>-like roles)<\/li>\n<li>who can create attestations (typically a CI service account)<\/li>\n<li>who can use KMS signing keys<\/li>\n<li>Attestations are <strong>cryptographically verified<\/strong> using attestor public keys.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>No special VPC plumbing is usually required beyond standard access to Google APIs by the control plane\/runtime.<\/li>\n<li>Private clusters and restricted networks may require careful Google API access design. Verify GKE private control plane\/API access requirements if you use restricted endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor:<\/li>\n<li>denied admissions (potential incidents or rollout issues)<\/li>\n<li>policy changes (audit events)<\/li>\n<li>KMS key usage for signing (audit)<\/li>\n<li>Governance:<\/li>\n<li>version policy changes in Git<\/li>\n<li>use Terraform or CI-controlled changes<\/li>\n<li>restrict who can modify policies and attestors<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer \/ CI] --&gt;|Build| AR[Artifact Registry]\n  Dev --&gt;|Sign\/Attest (KMS)| KMS[Cloud KMS]\n  Dev --&gt;|Create Attestation| CA[Container Analysis]\n  User[Deployer \/ GitOps] --&gt;|kubectl apply| GKE[GKE API Server]\n  GKE --&gt;|Evaluate Policy + Verify Attestation| BA[Binary Authorization]\n  BA --&gt; CA\n  BA --&gt;|Allow\/Deny| GKE\n  GKE --&gt;|Run Pods| Nodes[GKE Nodes]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Build[\"Build &amp; Security Pipeline\"]\n    Git[Source Repo] --&gt; CI[CI \/ Cloud Build]\n    CI --&gt; Tests[Unit\/Integration Tests]\n    Tests --&gt; ImageBuild[Build Container Image]\n    ImageBuild --&gt; AR[Artifact Registry]\n    AR --&gt; Scan[Vuln\/Policy Checks\\n(optional external tooling)]\n    Scan --&gt; AttestCI[CI Attestation]\n    AttestCI --&gt; CA[Container Analysis]\n    Sec[Security Team \/ Automated Gate] --&gt; AttestSec[Security Attestation]\n    AttestSec --&gt; CA\n    CI --&gt; KMS[Cloud KMS Asymmetric Keys]\n    AttestCI -.uses.-&gt; KMS\n    AttestSec -.uses.-&gt; KMS\n  end\n\n  subgraph Deploy[\"Deployment &amp; Runtime\"]\n    GitOps[GitOps Controller \/ CD] --&gt; GKEAPI[GKE API Server]\n    GKEAPI --&gt; BA[Binary Authorization Evaluation]\n    BA --&gt; CA\n    BA --&gt; Logs[Cloud Logging]\n    BA --&gt;|allow| Scheduler[Kubernetes Scheduler]\n    BA --&gt;|deny| Deny[Admission Denied]\n    Scheduler --&gt; Workloads[Pods\/Deployments]\n  end\n\n  OrgIAM[IAM \/ Org Policy \/ Separation of Duties] --&gt; CI\n  OrgIAM --&gt; BA\n  OrgIAM --&gt; KMS\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Google Cloud requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud project with <strong>billing enabled<\/strong><\/li>\n<li>Owner\/editor access for the lab, or equivalent granular IAM permissions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM roles (typical minimums for this tutorial)<\/h3>\n\n\n\n<p>Exact roles vary by org standards; verify in official docs and follow least privilege.<\/p>\n\n\n\n<p>You will commonly need:\n&#8211; For GKE:\n  &#8211; <code>roles\/container.admin<\/code> (or the specific permissions to create clusters and get credentials)\n&#8211; For Binary Authorization:\n  &#8211; <code>roles\/binaryauthorization.policyAdmin<\/code> (to set policy)\n  &#8211; <code>roles\/binaryauthorization.attestorsAdmin<\/code> (to create\/manage attestors)\n&#8211; For Container Analysis notes\/occurrences:\n  &#8211; <code>roles\/containeranalysis.notes.editor<\/code>\n  &#8211; <code>roles\/containeranalysis.occurrences.editor<\/code>\n&#8211; For Artifact Registry:\n  &#8211; <code>roles\/artifactregistry.admin<\/code> (lab) or narrower roles for repo creation and push\/pull\n&#8211; For Cloud KMS:\n  &#8211; <code>roles\/cloudkms.admin<\/code> (lab) and\/or <code>roles\/cloudkms.signerVerifier<\/code> (for signing)<\/p>\n\n\n\n<p>In production, split these across separate admin, CI, and security identities.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cloud.google.com\/sdk\/docs\/install\">Google Cloud CLI (<code>gcloud<\/code>)<\/a><\/li>\n<li><code>kubectl<\/code> (installed via <code>gcloud components install kubectl<\/code> or included with Cloud SDK installations; verify current install method)<\/li>\n<li>Optional: <code>docker<\/code> locally (you can also build via Cloud Build without local Docker)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>GKE and Artifact Registry are regional; Cloud KMS uses \u201clocations\u201d (including <code>global<\/code>).<\/li>\n<li>Choose a region supported by your org and quotas (for lab: <code>us-central1<\/code> is commonly used).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>GKE cluster quota (nodes, CPUs)<\/li>\n<li>Artifact Registry repo limits and storage<\/li>\n<li>Cloud KMS key and API usage<\/li>\n<li>Container Analysis API usage<\/li>\n<\/ul>\n\n\n\n<p>Always verify current quotas in your project: <strong>IAM &amp; Admin \u2192 Quotas<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs to enable<\/h3>\n\n\n\n<p>You will enable these APIs in the lab:\n&#8211; Kubernetes Engine API\n&#8211; Binary Authorization API\n&#8211; Container Analysis API\n&#8211; Artifact Registry API\n&#8211; Cloud Key Management Service (KMS) API\n&#8211; Cloud Build API (optional but used in this tutorial)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Binary Authorization pricing can change over time, and some related services have separate pricing. Always validate current costs using official sources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (what you pay for)<\/h3>\n\n\n\n<p>As of recent Google Cloud guidance, <strong>Binary Authorization itself is often listed as no additional charge<\/strong>, but your overall solution cost includes the services it depends on. <strong>Verify current Binary Authorization pricing<\/strong> here:\n&#8211; Official pricing landing pages often route through product pricing or the calculator; start with:\n  &#8211; https:\/\/cloud.google.com\/products\/calculator\n  &#8211; Binary Authorization docs: https:\/\/cloud.google.com\/binary-authorization\/docs (look for pricing notes)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions you should plan for (common cost drivers)<\/h3>\n\n\n\n<p>Even if Binary Authorization policy evaluation is not billed directly, you commonly pay for:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>GKE<\/strong>\n&#8211; Control plane and nodes (Standard) or pod-based billing (Autopilot).\n&#8211; Costs scale with cluster size, node type, and uptime.<\/p>\n<\/li>\n<li>\n<p><strong>Artifact Registry<\/strong>\n&#8211; Storage (GB-month)\n&#8211; Egress (data transfer out)\n&#8211; Operations\/requests (verify SKU model; Google Cloud pricing pages detail this)<\/p>\n<\/li>\n<li>\n<p><strong>Cloud Build (if used)<\/strong>\n&#8211; Build minutes, machine type, concurrency\n&#8211; Artifact storage for build logs and outputs<\/p>\n<\/li>\n<li>\n<p><strong>Cloud KMS<\/strong>\n&#8211; Key versions, key operations (signing), and key protection level (HSM vs software)\n&#8211; Signing each image (or each promotion) can add measurable KMS request volume<\/p>\n<\/li>\n<li>\n<p><strong>Container Analysis<\/strong>\n&#8211; Metadata storage and API usage (check current pricing; some scanning features have separate costs)<\/p>\n<\/li>\n<li>\n<p><strong>Cloud Logging<\/strong>\n&#8211; Log ingestion volume and retention (especially if you enable broad audit logs and high deploy frequency)<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud offers free tiers for some products; applicability changes.<\/li>\n<li>Assume <strong>GKE, Artifact Registry, KMS, and Logging can incur charges<\/strong> in a real environment.<\/li>\n<li>Confirm current free-tier eligibility in official pricing docs for each service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Engineering time to implement digest-based deployments and attestation lifecycle<\/li>\n<li>CI\/CD pipeline runtime increases (extra steps to sign and verify)<\/li>\n<li>Log volume and retention policies<\/li>\n<li>Key rotation operations and governance overhead<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pulling images across regions or out of Google Cloud can incur egress.<\/li>\n<li>Multi-region deployment with a single registry region can increase cross-region traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>one attestation per digest per environment stage<\/strong>, not per deployment attempt.<\/li>\n<li>Prefer <strong>promotion of the same digest<\/strong> to higher environments rather than rebuilding.<\/li>\n<li>Restrict logging to what you need; use log exclusions carefully (without losing security visibility).<\/li>\n<li>Choose KMS key types and rotation schedules aligned to security requirements; don\u2019t over-rotate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (qualitative)<\/h3>\n\n\n\n<p>A small lab environment typically costs money mainly from:\n&#8211; a small GKE cluster running for a short time\n&#8211; Artifact Registry storage for a few images\n&#8211; a handful of KMS signing operations\nYou can keep cost low by:\n&#8211; creating a minimal cluster\n&#8211; running the lab quickly\n&#8211; cleaning up immediately<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, cost scales with:\n&#8211; number of clusters\/environments\n&#8211; build frequency (KMS signing volume)\n&#8211; image size and pull frequency\n&#8211; logging volume\n&#8211; security scanning tooling integrated into the pipeline<\/p>\n\n\n\n<p>Use the Google Cloud Pricing Calculator to model your baseline and then add CI\/signing\/logging overhead.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Set up Binary Authorization for a GKE cluster so that:\n1. A deployment using an image <strong>without an attestation<\/strong> is <strong>blocked<\/strong>\n2. After you <strong>create a signed attestation<\/strong>, the same deployment is <strong>allowed<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create an Artifact Registry repository\n2. Build and push a sample container image\n3. Create a Cloud KMS asymmetric signing key\n4. Create a Binary Authorization attestor backed by a Container Analysis note\n5. Configure a Binary Authorization policy to require the attestor for images from your repo\n6. Create a GKE cluster with Binary Authorization enabled\n7. Attempt to deploy (expect denial)\n8. Create an attestation for the image digest\n9. Deploy again (expect success)\n10. Validate via kubectl and logs\n11. Clean up resources to avoid ongoing costs<\/p>\n\n\n\n<blockquote>\n<p>Notes:\n&#8211; Commands assume bash-like shell.\n&#8211; Replace variables as needed.\n&#8211; If any command flags differ in your environment, <strong>verify in official docs<\/strong> (CLI flags evolve).<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set variables and enable APIs<\/h3>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"$(gcloud config get-value project)\"\nexport REGION=\"us-central1\"\nexport REPO=\"binauthz-lab\"\nexport IMAGE=\"hello-binauthz\"\nexport ATTESTOR=\"build-attestor\"\nexport NOTE_ID=\"build-attestor-note\"\nexport KMS_LOCATION=\"global\"\nexport KMS_KEYRING=\"binauthz-kr\"\nexport KMS_KEY=\"binauthz-asym-key\"\n<\/code><\/pre>\n\n\n\n<p>Enable required APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  container.googleapis.com \\\n  artifactregistry.googleapis.com \\\n  cloudbuild.googleapis.com \\\n  binaryauthorization.googleapis.com \\\n  containeranalysis.googleapis.com \\\n  cloudkms.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enable successfully (may take 1\u20133 minutes).<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:binaryauthorization.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create an Artifact Registry repository<\/h3>\n\n\n\n<p>Create a Docker repository:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories create \"${REPO}\" \\\n  --repository-format=docker \\\n  --location=\"${REGION}\" \\\n  --description=\"Binary Authorization lab repo\"\n<\/code><\/pre>\n\n\n\n<p>Configure Docker authentication for Artifact Registry:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth configure-docker \"${REGION}-docker.pkg.dev\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Repository exists and Docker is configured to push.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories list --location=\"${REGION}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Build and push a sample container image (using Cloud Build)<\/h3>\n\n\n\n<p>Create a simple app:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p binauthz-lab &amp;&amp; cd binauthz-lab\n\ncat &gt; app.py &lt;&lt;'EOF'\nfrom flask import Flask\napp = Flask(__name__)\n\n@app.get(\"\/\")\ndef hello():\n    return \"Hello from Binary Authorization lab!\\n\"\nEOF\n\ncat &gt; requirements.txt &lt;&lt;'EOF'\nflask==3.0.3\ngunicorn==22.0.0\nEOF\n\ncat &gt; Dockerfile &lt;&lt;'EOF'\nFROM python:3.12-slim\nWORKDIR \/app\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\nCOPY app.py .\nCMD [\"gunicorn\", \"-b\", \"0.0.0.0:8080\", \"app:app\"]\nEOF\n<\/code><\/pre>\n\n\n\n<p>Build and push:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export IMAGE_URI=\"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/${IMAGE}:v1\"\n\ngcloud builds submit --tag \"${IMAGE_URI}\" .\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud Build completes and the image is pushed.<\/p>\n\n\n\n<p>Get the immutable image digest (important for attestations):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts docker images describe \"${IMAGE_URI}\" --format=\"value(image_summary.digest)\"\n<\/code><\/pre>\n\n\n\n<p>Store it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export DIGEST=\"$(gcloud artifacts docker images describe \"${IMAGE_URI}\" --format=\"value(image_summary.digest)\")\"\nexport IMAGE_BY_DIGEST=\"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/${IMAGE}@${DIGEST}\"\necho \"${IMAGE_BY_DIGEST}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have an <code>@sha256:...<\/code> reference.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Cloud KMS asymmetric signing key<\/h3>\n\n\n\n<p>Create a key ring:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud kms keyrings create \"${KMS_KEYRING}\" --location=\"${KMS_LOCATION}\"\n<\/code><\/pre>\n\n\n\n<p>Create an asymmetric signing key (ECC example):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud kms keys create \"${KMS_KEY}\" \\\n  --location=\"${KMS_LOCATION}\" \\\n  --keyring=\"${KMS_KEYRING}\" \\\n  --purpose=\"asymmetric-signing\" \\\n  --default-algorithm=\"ec-sign-p256-sha256\"\n<\/code><\/pre>\n\n\n\n<p>Get the key version resource name (usually version <code>1<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export KEY_VERSION=\"1\"\nexport KMS_KEY_VERSION_RESOURCE=\"projects\/${PROJECT_ID}\/locations\/${KMS_LOCATION}\/keyRings\/${KMS_KEYRING}\/cryptoKeys\/${KMS_KEY}\/cryptoKeyVersions\/${KEY_VERSION}\"\necho \"${KMS_KEY_VERSION_RESOURCE}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> KMS key exists and can be used for signing by your identity.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create a Container Analysis note for the attestor<\/h3>\n\n\n\n<p>Binary Authorization attestors use a Container Analysis <strong>note<\/strong> of kind <code>ATTESTATION_AUTHORITY<\/code>.<\/p>\n\n\n\n<p>Create the note using <code>curl<\/code> with an access token:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export CA_URL=\"https:\/\/containeranalysis.googleapis.com\/v1\/projects\/${PROJECT_ID}\/notes\/?noteId=${NOTE_ID}\"\n\ncurl -sS -X POST \\\n  -H \"Authorization: Bearer $(gcloud auth print-access-token)\" \\\n  -H \"Content-Type: application\/json\" \\\n  \"${CA_URL}\" \\\n  -d \"{\n    \\\"name\\\": \\\"projects\/${PROJECT_ID}\/notes\/${NOTE_ID}\\\",\n    \\\"attestation\\\": {\n      \\\"hint\\\": {\n        \\\"human_readable_name\\\": \\\"Build attestor note\\\"\n      }\n    }\n  }\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> JSON response indicating the note was created.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -sS \\\n  -H \"Authorization: Bearer $(gcloud auth print-access-token)\" \\\n  \"https:\/\/containeranalysis.googleapis.com\/v1\/projects\/${PROJECT_ID}\/notes\/${NOTE_ID}\" | head\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create a Binary Authorization attestor and add the KMS public key<\/h3>\n\n\n\n<p>Create the attestor:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestors create \"${ATTESTOR}\" \\\n  --attestation-authority-note=\"${NOTE_ID}\" \\\n  --attestation-authority-note-project=\"${PROJECT_ID}\"\n<\/code><\/pre>\n\n\n\n<p>Add a public key to the attestor from the Cloud KMS key version:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestors public-keys add \\\n  --attestor=\"${ATTESTOR}\" \\\n  --keyversion=\"${KMS_KEY_VERSION_RESOURCE}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Attestor exists and has a public key configured.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestors describe \"${ATTESTOR}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create and apply a Binary Authorization policy (enforce only for your repo)<\/h3>\n\n\n\n<p>Export the current policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz policy export &gt; policy.yaml\n<\/code><\/pre>\n\n\n\n<p>Edit <code>policy.yaml<\/code> so that:\n&#8211; Default is <strong>allow<\/strong> (to avoid blocking unrelated images)\n&#8211; Images in your repo require attestation by your attestor\n&#8211; Enforcement mode is blocking + audit logging<\/p>\n\n\n\n<p>A minimal example policy structure:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; policy.yaml &lt;&lt;EOF\nadmissionWhitelistPatterns: []\ndefaultAdmissionRule:\n  evaluationMode: ALWAYS_ALLOW\n  enforcementMode: ENFORCEMENT_MODE_UNSPECIFIED\nname: projects\/${PROJECT_ID}\/policy\nadmissionRules:\n  \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/*\":\n    evaluationMode: REQUIRE_ATTESTATION\n    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG\n    requireAttestationsBy:\n    - projects\/${PROJECT_ID}\/attestors\/${ATTESTOR}\nEOF\n<\/code><\/pre>\n\n\n\n<p>Import the policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz policy import policy.yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Policy imports successfully.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz policy export\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>If your <code>policy.yaml<\/code> structure differs from the API expectations in your environment, <strong>verify in official docs<\/strong>:\nhttps:\/\/cloud.google.com\/binary-authorization\/docs\/policy-yaml-reference (or the current reference path)<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a GKE cluster with Binary Authorization enabled<\/h3>\n\n\n\n<p>Create a small standard cluster (for a lab):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export CLUSTER=\"binauthz-cluster\"\n\ngcloud container clusters create \"${CLUSTER}\" \\\n  --region \"${REGION}\" \\\n  --num-nodes \"1\" \\\n  --machine-type \"e2-medium\" \\\n  --enable-ip-alias \\\n  --enable-binauthz\n<\/code><\/pre>\n\n\n\n<p>Get credentials:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters get-credentials \"${CLUSTER}\" --region \"${REGION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cluster is created; <code>kubectl<\/code> connects.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get nodes\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Attempt to deploy the image without an attestation (expect denial)<\/h3>\n\n\n\n<p>Create a Kubernetes deployment that references the image <strong>by digest<\/strong>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; deploy.yaml &lt;&lt;EOF\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: hello-binauthz\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: hello-binauthz\n  template:\n    metadata:\n      labels:\n        app: hello-binauthz\n    spec:\n      containers:\n      - name: app\n        image: ${IMAGE_BY_DIGEST}\n        ports:\n        - containerPort: 8080\nEOF\n<\/code><\/pre>\n\n\n\n<p>Apply it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl apply -f deploy.yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The deployment should be <strong>denied<\/strong> by Binary Authorization because no attestation exists yet. You should see an error similar to \u201cadmission denied\u201d referencing Binary Authorization policy.<\/p>\n\n\n\n<p>If it\u2019s not denied:\n&#8211; Confirm the cluster has Binary Authorization enabled\n&#8211; Confirm policy matches your image path pattern\n&#8211; Confirm you used the digest image reference\n&#8211; Check Troubleshooting below<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Create a signed attestation for the image digest<\/h3>\n\n\n\n<p>Create the attestation using the KMS key:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestations sign-and-create \\\n  --artifact-url=\"${IMAGE_BY_DIGEST}\" \\\n  --attestor=\"${ATTESTOR}\" \\\n  --attestor-project=\"${PROJECT_ID}\" \\\n  --keyversion=\"${KMS_KEY_VERSION_RESOURCE}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Attestation is created and stored in Container Analysis.<\/p>\n\n\n\n<p>Verify attestations:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestations list \\\n  --attestor=\"${ATTESTOR}\" \\\n  --attestor-project=\"${PROJECT_ID}\" \\\n  --artifact-url=\"${IMAGE_BY_DIGEST}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 11: Deploy again (expect success)<\/h3>\n\n\n\n<p>Re-apply:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl apply -f deploy.yaml\n<\/code><\/pre>\n\n\n\n<p>Check rollout:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl rollout status deployment\/hello-binauthz\nkubectl get pods -l app=hello-binauthz\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Pod is running successfully.<\/p>\n\n\n\n<p>(Optional) Expose via port-forward:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl port-forward deployment\/hello-binauthz 8080:8080\n<\/code><\/pre>\n\n\n\n<p>Then in another terminal:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -sS localhost:8080\/\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>1) Confirm the policy is set:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz policy export\n<\/code><\/pre>\n\n\n\n<p>2) Confirm the image has attestations:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestations list \\\n  --attestor=\"${ATTESTOR}\" \\\n  --attestor-project=\"${PROJECT_ID}\" \\\n  --artifact-url=\"${IMAGE_BY_DIGEST}\"\n<\/code><\/pre>\n\n\n\n<p>3) Confirm the workload is running:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get deploy hello-binauthz\nkubectl get pods -l app=hello-binauthz\n<\/code><\/pre>\n\n\n\n<p>4) Check logs for admission decisions (basic approach)\nBinary Authorization and Kubernetes admission denials can appear in Cloud Logging. A simple starting point is to search logs around the time of your denial in <strong>Logs Explorer<\/strong> and filter for \u201cBinary Authorization\u201d and your cluster name.<\/p>\n\n\n\n<p>You can also try:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud logging read \\\n  'textPayload:\"Binary Authorization\" OR protoPayload.status.message:\"Binary Authorization\"' \\\n  --limit=20 --freshness=1h\n<\/code><\/pre>\n\n\n\n<p>(Exact log fields vary; use Logs Explorer for reliable filtering.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Deployment was not blocked when it should be<\/h4>\n\n\n\n<p>Check:\n&#8211; Cluster created with <code>--enable-binauthz<\/code>\n&#8211; Policy rule matches your image reference:\n  &#8211; If the rule is <code>...\/${REPO}\/*<\/code> but your image is in a different repo or region, it won\u2019t match.\n&#8211; Image referenced by <strong>digest<\/strong> (<code>@sha256:<\/code>). If you used <code>:v1<\/code>, your attestation won\u2019t match a digest-only requirement.\n&#8211; Ensure the policy is imported into the correct project (<code>name: projects\/${PROJECT_ID}\/policy<\/code>).<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: <code>PERMISSION_DENIED<\/code> when creating note or attestor<\/h4>\n\n\n\n<p>You likely need Container Analysis permissions:\n&#8211; <code>roles\/containeranalysis.notes.editor<\/code> to create notes\n&#8211; <code>roles\/binaryauthorization.attestorsAdmin<\/code> to create attestors<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: <code>PERMISSION_DENIED<\/code> when signing attestation with KMS<\/h4>\n\n\n\n<p>Your identity (or CI service account) needs KMS signing permissions:\n&#8211; <code>roles\/cloudkms.signerVerifier<\/code> on the key (or a more restrictive custom role granting <code>cloudkms.cryptoKeyVersions.useToSign<\/code>)<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Attestation created, but deployment still denied<\/h4>\n\n\n\n<p>Common causes:\n&#8211; Attested a different image digest than the one in the manifest\n&#8211; Policy requires a different attestor, or multiple attestations\n&#8211; Attestor public keys don\u2019t match the key used to sign (key rotation mismatch)<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: <code>kubectl apply<\/code> error message isn\u2019t clear<\/h4>\n\n\n\n<p>Use:\n&#8211; <code>kubectl -v=6 apply -f deploy.yaml<\/code> for more client-side details\n&#8211; Cloud Logging Logs Explorer to see admission webhook denial details<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs, delete resources when done.<\/p>\n\n\n\n<p>Delete Kubernetes resources:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl delete -f deploy.yaml --ignore-not-found\n<\/code><\/pre>\n\n\n\n<p>Delete the cluster:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters delete \"${CLUSTER}\" --region \"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete Artifact Registry repository (deletes images inside):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories delete \"${REPO}\" --location \"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete Binary Authorization attestor (optional):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestors delete \"${ATTESTOR}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Reset policy (optional: export baseline before changing in real projects). For the lab, you can set default allow:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; policy-reset.yaml &lt;&lt;EOF\nadmissionWhitelistPatterns: []\ndefaultAdmissionRule:\n  evaluationMode: ALWAYS_ALLOW\n  enforcementMode: ENFORCEMENT_MODE_UNSPECIFIED\nname: projects\/${PROJECT_ID}\/policy\nEOF\n\ngcloud container binauthz policy import policy-reset.yaml\n<\/code><\/pre>\n\n\n\n<p>Delete KMS key ring (must delete keys first; KMS deletion is constrained\u2014keys often have destruction scheduling). For labs, you may leave KMS resources if deletion policies are complex. If you do manage key destruction, follow Cloud KMS procedures:\n&#8211; https:\/\/cloud.google.com\/kms\/docs\/destroy-restore<\/p>\n\n\n\n<p>Delete the Container Analysis note (optional; may require specific permissions):<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -sS -X DELETE \\\n  -H \"Authorization: Bearer $(gcloud auth print-access-token)\" \\\n  \"https:\/\/containeranalysis.googleapis.com\/v1\/projects\/${PROJECT_ID}\/notes\/${NOTE_ID}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Design for promotion by digest:<\/strong> Build once, promote the same digest through environments.<\/li>\n<li><strong>Require multiple attestations for production:<\/strong> e.g., CI + security gate.<\/li>\n<li><strong>Use environment-specific policies:<\/strong> dev can be audit-only; prod enforces.<\/li>\n<li><strong>Minimize allowlists:<\/strong> treat allowlist patterns as temporary exceptions with owners and expiry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate duties with separate identities:<\/strong><\/li>\n<li>Platform admin manages policy<\/li>\n<li>CI service account signs CI attestations<\/li>\n<li>Security service account signs security attestations<\/li>\n<li>Restrict who can:<\/li>\n<li>change Binary Authorization policy<\/li>\n<li>add\/remove attestor public keys<\/li>\n<li>create attestations<\/li>\n<li>Use <strong>least privilege<\/strong>:<\/li>\n<li>CI gets <code>cloudkms.signerVerifier<\/code> on only the required key<\/li>\n<li>Don\u2019t grant broad editor\/owner to pipelines<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Attest <strong>once per digest per stage<\/strong>, not on every deploy attempt.<\/li>\n<li>Keep clusters right-sized; don\u2019t run lab clusters longer than needed.<\/li>\n<li>Manage Logging retention and avoid excessive verbosity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use clear, minimal policies; avoid complex, overly broad rule sets.<\/li>\n<li>Prefer deterministic artifact naming and repo patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Roll out policy in <strong>dry-run<\/strong> first; monitor denials before enforcing.<\/li>\n<li>Maintain a tested break-glass procedure (and audit it).<\/li>\n<li>Store policy-as-code in version control with reviews.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralize logs and set alerts on spikes in denials (possible attack or pipeline break).<\/li>\n<li>Document the signing\/attestation workflow and key rotation procedures.<\/li>\n<li>Use Infrastructure as Code (Terraform) for repeatable, reviewed changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Name attestors by purpose and stage: <code>ci-attestor<\/code>, <code>security-attestor<\/code>, <code>prod-release-attestor<\/code>.<\/li>\n<li>Label repos and clusters by environment.<\/li>\n<li>Keep a registry of exception patterns and owners.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<p>Binary Authorization relies heavily on IAM:\n&#8211; Policy admin access is highly sensitive: it can effectively decide what runs.\n&#8211; Attestor admin access is sensitive: changing public keys can undermine verification.\n&#8211; Attestation signing access is sensitive: signing is an approval action.<\/p>\n\n\n\n<p>Recommendations:\n&#8211; Use separate projects or at least separate service accounts for build vs prod approvals.\n&#8211; Consider organization-level controls and approvals for production policy changes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Container images in Artifact Registry are encrypted at rest by Google by default; some orgs require CMEK\u2014verify current options.<\/li>\n<li>Attestations stored in Container Analysis are also protected by Google\u2019s infrastructure security.<\/li>\n<li>Cloud KMS keys provide cryptographic control and auditing for signing operations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Binary Authorization enforcement is tied to the control plane admission path of the runtime (e.g., GKE API server).<\/li>\n<li>Ensure your cluster API access (public\/private endpoint) follows your security requirements.<\/li>\n<li>For private or restricted environments, verify Google API access paths and firewall rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Don\u2019t store private keys in CI as plaintext files if you can use Cloud KMS signing.<\/li>\n<li>If you must use external signing systems, store secrets in Secret Manager and limit access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and retain:<\/li>\n<li>Admin activity logs for IAM changes, KMS usage, policy changes<\/li>\n<li>Admission denials for operational visibility<\/li>\n<li>Build dashboards\/alerts:<\/li>\n<li>sudden increase in denials<\/li>\n<li>policy changes outside change windows<\/li>\n<li>unusual KMS signing activity<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Binary Authorization can support compliance goals by enforcing artifact approval at deploy time, but:\n&#8211; Compliance requires process + evidence. Keep policy changes and attestation creation auditable.\n&#8211; Pair with vulnerability management and patch policies.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Using <code>ALWAYS_ALLOW<\/code> in production indefinitely.<\/li>\n<li>Over-broad allowlist patterns that effectively disable enforcement.<\/li>\n<li>Allowing developers to both build and sign production approvals.<\/li>\n<li>Not pinning images by digest.<\/li>\n<li>Treating attestations as \u201cset and forget\u201d without key rotation and lifecycle management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with dry-run in staging; enforce in prod after you observe stable behavior.<\/li>\n<li>Require at least one CI attestation and one independent security attestation for production.<\/li>\n<li>Use Cloud KMS keys with strict IAM and audit.<\/li>\n<li>Keep policy-as-code with mandatory review for production changes.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Always confirm current limitations in official docs for your target runtime.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common limitations \/ gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Digest discipline is required:<\/strong> Attestations are for image digests. If your deployment uses tags, you can get mismatches or ineffective controls.<\/li>\n<li><strong>Policy scope is project-centric:<\/strong> Multi-project organizations must plan how policies\/attestors and attestations are managed across environments.<\/li>\n<li><strong>Allowlists can undermine security:<\/strong> Excessive exemptions defeat the purpose.<\/li>\n<li><strong>Key rotation requires planning:<\/strong> If you rotate KMS keys or change attestor keys, you must ensure verification remains consistent.<\/li>\n<li><strong>CI\/CD complexity:<\/strong> Pipelines must reliably produce attestations; outages in signing steps can block releases.<\/li>\n<li><strong>Logging can be noisy:<\/strong> High deployment frequency can produce significant logs; tune alerts and retention.<\/li>\n<li><strong>Cluster\/system images:<\/strong> If you set overly broad \u201crequire attestation for everything,\u201d you may accidentally block images you didn\u2019t intend to govern. Prefer targeted rules (as shown in the lab) and test carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<p>Quotas vary by service (GKE, KMS, Container Analysis, Logging). Track:\n&#8211; KMS request rate if signing frequently\n&#8211; Logging ingestion\n&#8211; Artifact Registry storage and requests<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry repositories are regional (or multi-regional depending on setup).<\/li>\n<li>GKE clusters are regional\/zonal.<\/li>\n<li>KMS locations must be selected intentionally (<code>global<\/code> is common for keys, but org requirements may differ).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>KMS signing operations at large scale<\/li>\n<li>Cross-region artifact pulls<\/li>\n<li>Logging ingestion\/retention at high scale<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Binary Authorization\u2019s supported targets and feature set can evolve. Verify supported runtimes and configuration specifics in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving from tag-based deployments to digest-based deployments can require changes in:<\/li>\n<li>Helm charts\/Kustomize<\/li>\n<li>GitOps tooling<\/li>\n<li>Release processes and rollback strategies<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Binary Authorization focuses on <strong>deploy-time image trust enforcement<\/strong>. It is often used alongside other controls.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Cloud Binary Authorization<\/strong><\/td>\n<td>Enforcing trusted images on GKE (and supported Google Cloud runtimes)<\/td>\n<td>Managed service; strong integration with GKE, Container Analysis, Cloud KMS; auditability<\/td>\n<td>Requires digest + attestation workflow; policy design needed to avoid accidental blocks<\/td>\n<td>You want Google Cloud\u2013native, enforced image admission control<\/td>\n<\/tr>\n<tr>\n<td>GKE Kubernetes admission policies (general)<\/td>\n<td>Broad Kubernetes governance<\/td>\n<td>Flexible for many policies beyond images<\/td>\n<td>Not specifically a cryptographic attestation system; you must build signing logic<\/td>\n<td>You need runtime policy controls beyond artifact trust (use with Binary Authorization)<\/td>\n<\/tr>\n<tr>\n<td>Policy Controller \/ Gatekeeper (OPA) on GKE<\/td>\n<td>Policy-as-code for Kubernetes resources<\/td>\n<td>Very flexible constraints (labels, namespaces, RBAC patterns)<\/td>\n<td>Doesn\u2019t natively solve signed artifact attestation (needs integration)<\/td>\n<td>You need Kubernetes governance in addition to image trust<\/td>\n<\/tr>\n<tr>\n<td>Kyverno (in-cluster)<\/td>\n<td>Kubernetes-native policy and image verification features<\/td>\n<td>Strong K8s-native UX; can do some image verification patterns<\/td>\n<td>You operate and secure the controller yourself; cluster-level ops overhead<\/td>\n<td>You need portable Kubernetes policy across clouds and prefer in-cluster enforcement<\/td>\n<\/tr>\n<tr>\n<td>Sigstore\/cosign + custom admission<\/td>\n<td>Portable signing\/verification<\/td>\n<td>Cloud-agnostic; modern OSS ecosystem<\/td>\n<td>You must integrate and operate verification; key management choices vary<\/td>\n<td>You need multi-cloud portability and custom supply-chain tooling<\/td>\n<\/tr>\n<tr>\n<td>AWS: EKS + ECR + admission controls<\/td>\n<td>AWS-native approach<\/td>\n<td>Integrated AWS tooling for registries and scanning<\/td>\n<td>No direct equivalent that matches Binauthz semantics 1:1; you assemble components<\/td>\n<td>You are standardized on AWS and want AWS-native controls<\/td>\n<\/tr>\n<tr>\n<td>Azure: AKS + ACR + policy controls<\/td>\n<td>Azure-native approach<\/td>\n<td>Azure Policy for AKS integration is strong for governance<\/td>\n<td>Image trust enforcement approach differs; may require additional tooling<\/td>\n<td>You are standardized on Azure and want Azure-native governance<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<p>In practice, Binary Authorization is commonly paired with:\n&#8211; vulnerability scanning (in Artifact Registry\/Container Analysis or third-party tooling)\n&#8211; Kubernetes policy (OPA\/Gatekeeper or alternatives)\n&#8211; CI\/CD provenance (Cloud Build, GitHub Actions, etc.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated organization)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A bank runs multiple GKE clusters handling sensitive workloads. Auditors require proof that only approved builds reach production, and security wants to prevent manual image pushes or tag manipulation.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Artifact Registry per environment (or per org) with controlled write access<\/li>\n<li>Cloud Build builds images and signs CI attestations using Cloud KMS<\/li>\n<li>Security scanning pipeline produces a second attestation (security attestor)<\/li>\n<li>Production GKE clusters enforce Binary Authorization requiring both attestations for images from the production repo path<\/li>\n<li>Centralized Cloud Logging + SIEM integration for denied deploys and policy changes<\/li>\n<li><strong>Why Binary Authorization was chosen:<\/strong><\/li>\n<li>Enforced at deploy time (not just advisory)<\/li>\n<li>Cryptographic attestations with KMS-backed keys<\/li>\n<li>Strong integration with GKE and Google Cloud audit logging<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Significant reduction in unapproved deployments<\/li>\n<li>Strong evidence for compliance audits (attestations + logs)<\/li>\n<li>Faster incident response when suspicious deploys are attempted<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (lean platform)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup has a small SRE team and multiple developers deploying microservices to a single GKE cluster. They had incidents caused by deploying the wrong image tag and want a low-friction safety gate.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>One Artifact Registry repo<\/li>\n<li>One CI attestor (Cloud Build) signing attestation after tests pass<\/li>\n<li>Binary Authorization policy enforces attestation only for that repo path<\/li>\n<li>Dry-run in dev namespace first (or dev cluster), then enforce in production<\/li>\n<li><strong>Why Binary Authorization was chosen:<\/strong><\/li>\n<li>Minimal operational burden (managed service)<\/li>\n<li>Immediately stops tag-drift and \u201cmanual deploy\u201d mistakes<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Fewer rollbacks from wrong artifacts<\/li>\n<li>Faster, safer deployments with a consistent approval step<\/li>\n<li>Clear audit trail without heavy process<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Binary Authorization a container registry?<\/strong><br\/>\nNo. It enforces policies about what images may be deployed. You typically use it with Artifact Registry (image storage) and Container Analysis (attestation storage).<\/p>\n\n\n\n<p>2) <strong>Does Binary Authorization scan images for vulnerabilities?<\/strong><br\/>\nNot by itself. It enforces based on policy and attestations. Vulnerability scanning is typically done by other services\/tools, and the result can be used to decide whether to attest.<\/p>\n\n\n\n<p>3) <strong>Why do I need image digests instead of tags?<\/strong><br\/>\nTags are mutable. Digests are immutable and uniquely identify the exact image content. Attestations bind approvals to digests.<\/p>\n\n\n\n<p>4) <strong>What is an attestor?<\/strong><br\/>\nAn attestor is a trusted authority definition (with public keys) that can verify signed attestations.<\/p>\n\n\n\n<p>5) <strong>What is an attestation?<\/strong><br\/>\nA signed approval statement for a specific image digest, stored in Container Analysis and verified at deploy time.<\/p>\n\n\n\n<p>6) <strong>Can I require multiple approvals?<\/strong><br\/>\nYes. Policies can require attestations from multiple attestors (common for CI + Security separation of duties).<\/p>\n\n\n\n<p>7) <strong>How does Binary Authorization integrate with GKE?<\/strong><br\/>\nWhen enabled, GKE evaluates the Binary Authorization policy during admission. If the image doesn\u2019t satisfy policy, the deploy is denied.<\/p>\n\n\n\n<p>8) <strong>Will enabling Binary Authorization break my cluster?<\/strong><br\/>\nIt can if you enforce too broadly without allowlists or targeted rules. Start with dry-run and\/or target only your application image patterns.<\/p>\n\n\n\n<p>9) <strong>What happens when a deployment is denied?<\/strong><br\/>\nThe admission request is rejected and logged. No pods are scheduled.<\/p>\n\n\n\n<p>10) <strong>Can I use Cloud KMS for keys?<\/strong><br\/>\nYes, commonly. Cloud KMS can store and use asymmetric signing keys so private keys are not exported.<\/p>\n\n\n\n<p>11) <strong>Who should be allowed to change the policy?<\/strong><br\/>\nA small set of platform\/security admins. Policy changes are sensitive and should be reviewed and audited.<\/p>\n\n\n\n<p>12) <strong>How do I implement break-glass?<\/strong><br\/>\nTypically by temporarily switching enforcement mode to audit-only or adjusting rules. Restrict who can do this and log\/alert on changes.<\/p>\n\n\n\n<p>13) <strong>How does this fit with GitOps?<\/strong><br\/>\nBinary Authorization still applies because enforcement happens at admission time, independent of who applies manifests.<\/p>\n\n\n\n<p>14) <strong>Do attestations need to be created per deployment?<\/strong><br\/>\nNo. Attestations are created per image digest. The same digest can be deployed many times without re-attesting.<\/p>\n\n\n\n<p>15) <strong>Can I use Binary Authorization across multiple projects?<\/strong><br\/>\nYes, but you must design where policies live and where attestations are stored. Cross-project patterns require careful IAM and architecture\u2014verify current best practices in official docs.<\/p>\n\n\n\n<p>16) <strong>What\u2019s the difference between allowlists and attestations?<\/strong><br\/>\nAllowlists bypass checks for matching images. Attestations prove approval cryptographically. Prefer attestations; keep allowlists minimal.<\/p>\n\n\n\n<p>17) <strong>How do I troubleshoot a denial quickly?<\/strong><br\/>\nCheck: image digest, policy rule match, required attestors, existence of attestations, and Cloud Logging entries around the denial time.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Binary Authorization<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official Documentation<\/td>\n<td>Binary Authorization docs \u2014 https:\/\/cloud.google.com\/binary-authorization\/docs<\/td>\n<td>Canonical product documentation, concepts, policy and attestor guidance<\/td>\n<\/tr>\n<tr>\n<td>Official Tutorial \/ Guide<\/td>\n<td>Binary Authorization with GKE (verify current guide path) \u2014 start at https:\/\/cloud.google.com\/binary-authorization\/docs<\/td>\n<td>Step-by-step guidance for enabling enforcement on GKE<\/td>\n<\/tr>\n<tr>\n<td>Official Reference<\/td>\n<td>gcloud binauthz command reference \u2014 https:\/\/cloud.google.com\/sdk\/gcloud\/reference\/container\/binauthz<\/td>\n<td>CLI commands for attestors, attestations, and policy<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>Container Analysis docs \u2014 https:\/\/cloud.google.com\/container-analysis\/docs<\/td>\n<td>Explains notes\/occurrences storage model used for attestations<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>Artifact Registry docs \u2014 https:\/\/cloud.google.com\/artifact-registry\/docs<\/td>\n<td>Image storage, auth, repo configuration, and digest usage<\/td>\n<\/tr>\n<tr>\n<td>Official Documentation<\/td>\n<td>Cloud KMS docs \u2014 https:\/\/cloud.google.com\/kms\/docs<\/td>\n<td>Key management, asymmetric signing, IAM, rotation, destruction<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Model end-to-end costs (GKE + registry + KMS + logging)<\/td>\n<\/tr>\n<tr>\n<td>Architecture Guidance<\/td>\n<td>Google Cloud Architecture Center \u2014 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures (search supply-chain security, GKE security)<\/td>\n<\/tr>\n<tr>\n<td>Official Videos<\/td>\n<td>Google Cloud Tech YouTube \u2014 https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Product explanations and demos (search \u201cBinary Authorization\u201d)<\/td>\n<\/tr>\n<tr>\n<td>Samples<\/td>\n<td>GoogleCloudPlatform GitHub org \u2014 https:\/\/github.com\/GoogleCloudPlatform<\/td>\n<td>Look for official or trusted samples involving binauthz\/attestation (verify repo relevance)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps, CI\/CD, cloud security concepts, Kubernetes governance<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>Software configuration management, DevOps fundamentals<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations and platform teams<\/td>\n<td>Cloud operations, automation, monitoring, security basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations teams<\/td>\n<td>Reliability engineering, production ops, governance<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams adopting automation<\/td>\n<td>AIOps concepts, operations automation, monitoring analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud coaching (verify exact topics on site)<\/td>\n<td>Engineers seeking hands-on guidance<\/td>\n<td>https:\/\/www.rajeshkumar.xyz<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training (verify course catalog)<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>https:\/\/www.devopstrainer.in<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps consulting\/training (verify offerings)<\/td>\n<td>Teams needing practical implementation help<\/td>\n<td>https:\/\/www.devopsfreelancer.com<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify offerings)<\/td>\n<td>Ops teams needing troubleshooting and support<\/td>\n<td>https:\/\/www.devopssupport.in<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify offerings)<\/td>\n<td>Platform engineering, cloud migrations, security posture<\/td>\n<td>Implement Binary Authorization on GKE; CI\/CD signing workflow; IAM hardening<\/td>\n<td>https:\/\/www.cotocus.com<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training (verify offerings)<\/td>\n<td>DevOps transformation, CI\/CD, Kubernetes practices<\/td>\n<td>Establish artifact promotion + attestation process; policy-as-code; rollout strategy<\/td>\n<td>https:\/\/www.devopsschool.com<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify offerings)<\/td>\n<td>Cloud ops, pipeline automation, Kubernetes governance<\/td>\n<td>Build end-to-end supply-chain controls with Artifact Registry + KMS + Binary Authorization<\/td>\n<td>https:\/\/www.devopsconsulting.in<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Binary Authorization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Containers fundamentals: images, registries, tags vs digests<\/li>\n<li>Kubernetes basics: deployments, pods, admission control conceptually<\/li>\n<li>Google Cloud basics: projects, IAM, service accounts<\/li>\n<li>Artifact Registry basics: repositories, auth, pushing\/pulling images<\/li>\n<li>CI\/CD basics: build pipelines, promotion, environment separation<\/li>\n<li>Cryptography basics (helpful): asymmetric keys, signing vs encryption<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Binary Authorization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced supply-chain security:<\/li>\n<li>provenance, SBOMs, SLSA concepts<\/li>\n<li>Kubernetes policy governance:<\/li>\n<li>OPA\/Gatekeeper (Policy Controller), Kyverno<\/li>\n<li>Secrets management:<\/li>\n<li>Secret Manager, Workload Identity on GKE<\/li>\n<li>Observability:<\/li>\n<li>Logging\/Monitoring dashboards and alerting on policy denials<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>Terraform for policies, attestors, registry, GKE configuration<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud security engineer<\/li>\n<li>DevSecOps engineer<\/li>\n<li>Platform engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Cloud solutions architect<\/li>\n<li>Kubernetes administrator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Google Cloud certifications that align well (verify current certification names\/paths):\n&#8211; Professional Cloud Security Engineer\n&#8211; Professional Cloud DevOps Engineer\n&#8211; Professional Cloud Architect\nUse Binary Authorization as a practical project topic for security and platform design discussions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a 2-attestor workflow (CI + Security) with separate service accounts and keys.<\/li>\n<li>Implement \u201cpromotion attestations\u201d for staging \u2192 prod using the same digest.<\/li>\n<li>Add alerting on Binary Authorization denials and policy changes.<\/li>\n<li>Convert an existing Helm chart to use digest pinning and update pipeline to automatically attest.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Admission control (Kubernetes):<\/strong> A stage where API requests are validated\/modified\/accepted or rejected before being persisted.<\/li>\n<li><strong>Artifact Registry:<\/strong> Google Cloud service for storing and managing container images and artifacts.<\/li>\n<li><strong>Attestation:<\/strong> A signed approval statement for an image digest.<\/li>\n<li><strong>Attestor:<\/strong> A trusted authority definition used to verify attestations.<\/li>\n<li><strong>Binary Authorization Policy:<\/strong> Rules defining which images need which attestations and how enforcement behaves.<\/li>\n<li><strong>Cloud KMS:<\/strong> Google Cloud Key Management Service; manages cryptographic keys and performs signing operations.<\/li>\n<li><strong>Container Analysis:<\/strong> Service that stores metadata about artifacts (Grafeas notes\/occurrences), including attestations.<\/li>\n<li><strong>Digest:<\/strong> Immutable identifier of an image (e.g., <code>sha256:...<\/code>), derived from content.<\/li>\n<li><strong>Enforcement mode:<\/strong> Whether violations are blocked or only logged (dry-run\/audit).<\/li>\n<li><strong>Grafeas:<\/strong> Open metadata API model used by Container Analysis (notes and occurrences).<\/li>\n<li><strong>IAM (Identity and Access Management):<\/strong> Google Cloud access control system for resources and actions.<\/li>\n<li><strong>Policy-as-code:<\/strong> Managing policies in version control and applying via CI rather than manual console edits.<\/li>\n<li><strong>Separation of duties:<\/strong> Control principle where no single actor can both produce and approve critical artifacts.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Binary Authorization is a Google Cloud <strong>Security<\/strong> service that enforces <strong>deploy-time trust<\/strong> for container images by requiring policy-defined <strong>attestations<\/strong> before workloads can run (commonly on <strong>GKE<\/strong>). It matters because it helps prevent unapproved or tampered images from reaching production, improves auditability, and strengthens your software supply chain.<\/p>\n\n\n\n<p>From a cost perspective, the main drivers are usually <strong>GKE<\/strong>, <strong>Artifact Registry<\/strong>, <strong>Cloud KMS signing operations<\/strong>, <strong>Container Analysis usage<\/strong>, and <strong>Logging volume<\/strong>\u2014not necessarily Binary Authorization itself (verify current pricing in official sources). From a security perspective, success depends on strong <strong>IAM separation of duties<\/strong>, digest-based deployments, careful policy rollout (dry-run first), and disciplined key management.<\/p>\n\n\n\n<p>Use Binary Authorization when you need a reliable, enforced gate that ensures <strong>only approved images run<\/strong>. Next, deepen your implementation by adding multi-attestor workflows, promotion-by-digest, and operational alerting on denials and policy changes.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,10],"tags":[],"class_list":["post-795","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-security"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/795","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=795"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/795\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=795"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=795"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=795"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}