Enforce supply chain policies in GKE with Binary Authorization

Introduction

When you deploy AI inference containers to GKE without enforcing attestation requirements, any image—including those bundling unverified model weights or compromised runtimes—can reach production unchecked. A single misconfigured image in an inference cluster can expose sensitive data, execute malicious payloads embedded in model files, or silently undo the supply chain guarantees you established with model signing and AI-BOM generation earlier in this chapter. Binary Authorization closes this gap by acting as a cryptographic gatekeeper at the Kubernetes admission layer, blocking any pod whose image lacks the required signed attestations. By the end of this lesson, you'll be able to write a Binary Authorization policy that enforces a default-deny rule requiring all three supply-chain attestations, configure namespace-scoped overrides for development environments, and validate your policy safely in dry-run mode before enforcing it against live workloads.

Key Terminology

• Binary Authorization — GKE's cryptographic admission controller that intercepts every pod creation request and blocks it if the container image digest lacks signed attestations from all named attestors required by the active policy.
• Attestor — A named GCP resource (e.g., projects/my-project/attestors/model-provenance) that represents one verification step in the supply chain; Binary Authorization checks whether every required attestor has produced a valid signature for the image before admitting the pod.
• defaultAdmissionRule — The baseline rule applied to any image that does not match an admissionWhitelistPatterns entry; in this lesson it requires all three attestors (vulnerability-scan, model-provenance, ai-bom-validation) and uses ENFORCED_BLOCK_AND_AUDIT_LOG to hard-block non-compliant images.
• clusterAdmissionRules — A per-cluster override block in the policy YAML that replaces the defaultAdmissionRule for a named cluster; used here to apply single-attestor dry-run enforcement to the dev cluster while maintaining the full three-attestor gate on the inference cluster.
• admissionWhitelistPatterns — Glob-based exemption entries (e.g., gcr.io/google-containers/*) whose matching images bypass attestation requirements entirely; used for Google-managed system images and pre-hardened base images that satisfy trust through a separate pipeline.
• DRYRUN_AUDIT_LOG_ONLY — An enforcementMode value that records which images would have been blocked in Cloud Audit Logs without actually rejecting them, enabling safe policy validation before promoting to the ENFORCED_BLOCK_AND_AUDIT_LOG mode used in production.

Concepts

Binary Authorization as the Supply-Chain Enforcement Point

Binary Authorization sits at the Kubernetes admission layer — it intercepts every pod creation request before the scheduler ever sees it. Unlike CI/CD gates that live outside the cluster, this control cannot be bypassed by someone with direct cluster credentials who skips the pipeline. Enforcement is owned by GKE itself, not by process discipline.

This placement is what makes Binary Authorization the convergence point for the AI supply chain work done earlier in this chapter. Model files verified by OpenSSF Model Signing, dependency graphs captured in SPDX 3 AI-BOMs, and container vulnerability results from Trivy each produce a signed attestation tied to a specific image digest. Binary Authorization is where those attestations become enforceable: absent a required attestor's signature on the digest, the pod is blocked before any workload runs. No attestation, no admission.

Default-Deny with Layered Overrides

The mental model for a Binary Authorization policy is a stack of rules evaluated from most specific to most general. admissionWhitelistPatterns sits at the top: images matching those glob patterns (Google-managed system containers, pre-hardened base images) skip attestation entirely. Everything that falls through hits the clusterAdmissionRules block, where per-cluster entries override the global baseline for named clusters. Anything that doesn't match a cluster entry is governed by defaultAdmissionRule — the catch-all that applies to every cluster not explicitly listed.

This layering enforces least-privilege by default. A new cluster added to the fleet automatically inherits the strict global default — three attestors required, hard block — rather than silently inheriting a relaxed dev policy. Exceptions must be declared explicitly, which means the policy file becomes an auditable record of every deliberate trust decision (see Code Walkthrough).

Safe Progressive Rollout with Dry-Run Mode

Flipping enforcement from audit-only to blocking is a one-way gate: any image that cannot produce the required attestations will fail to deploy immediately. DRYRUN_AUDIT_LOG_ONLY on the dev cluster lets you observe coverage gaps in Cloud Audit Logs — which images would have been denied and why — without interrupting running workloads. This is the recommended rollout sequence: apply the policy to the dev cluster first, review audit log denials, resolve missing attestors or misconfigured pipelines, then promote the policy to the inference cluster with ENFORCED_BLOCK_AND_AUDIT_LOG.

The Python helper that calls gcloud container binauthz policy import`` uses check=True in subprocess.run so a malformed policy file raises CalledProcessError immediately rather than silently overwriting a working policy with a broken one. Pair that with gcloud container binauthz policy export after import to confirm the three attestors are present in defaultAdmissionRule and that the dev cluster entry still shows DRYRUN_AUDIT_LOG_ONLY before touching the inference cluster.

Code Walkthrough

Now that you understand the policy configuration patterns Binary Authorization supports, the next step is writing and applying a policy that encodes all four elements covered in the Concepts section: a default-deny rule, namespace-specific overrides, exemption patterns for pre-approved images, and dry-run mode for safe rollout.

The policy below enforces all three attestors in production while relaxing to a single attestor and dry-run mode in the development cluster:

Code snippetyaml
1# binary-authorization-policy.yaml
2admissionWhitelistPatterns:
3  - namePattern: gcr.io/google-containers/*
4  - namePattern: gcr.io/my-org/hardened-base/*
5defaultAdmissionRule:
6  evaluationMode: REQUIRE_ATTESTATION
7  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
8  requireAttestationsBy:
9    - projects/my-project/attestors/vulnerability-scan
10    - projects/my-project/attestors/model-provenance
11    - projects/my-project/attestors/ai-bom-validation
12clusterAdmissionRules:
13  us-central1-a.inference-cluster:
14    evaluationMode: REQUIRE_ATTESTATION
15    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
16    requireAttestationsBy:
17      - projects/my-project/attestors/vulnerability-scan
18      - projects/my-project/attestors/model-provenance
19      - projects/my-project/attestors/ai-bom-validation
20  us-central1-a.dev-cluster:
21    evaluationMode: REQUIRE_ATTESTATION
22    enforcementMode: DRYRUN_AUDIT_LOG_ONLY
23    requireAttestationsBy:
24      - projects/my-project/attestors/vulnerability-scan
25globalPolicyEvaluationMode: ENABLE

The admissionWhitelistPatterns block handles the exemption patterns: Google-managed system images and your organization's pre-hardened base images bypass attestation requirements entirely. The defaultAdmissionRule sets the global baseline—any image that does not match a whitelist pattern must carry all three attestations or be blocked. The clusterAdmissionRules block overrides that default per cluster: the inference cluster enforces the full three-attestor requirement with hard blocking, while the dev cluster accepts images carrying only the vulnerability scan attestation and logs denials rather than enforcing them, giving data scientists room to iterate on model versions without running the full pipeline.

Once the policy file is ready, apply it using the gcloud Binary Authorization import command:

Code snippetpython
1import subprocess
2
3def apply_binary_authorization_policy(project_id: str, policy_file: str) -> None:
4    """Apply a Binary Authorization policy from a YAML file."""
5    result = subprocess.run(
6        [
7            "gcloud", "container", "binauthz", "policy", "import",
8            policy_file,
9            "--project", project_id,
10        ],
11        capture_output=True,
12        text=True,
13        check=True,
14    )
15    print(result.stdout)
16
17apply_binary_authorization_policy("my-project", "binary-authorization-policy.yaml")

The check=True argument raises subprocess.CalledProcessError immediately if the import fails, so a misconfigured policy never silently replaces a working one. Run this against the dev cluster first; the dry-run enforcement mode means any image that would have been blocked is only logged, not rejected, giving you a chance to review Cloud Audit Logs for unexpected denials before promoting the policy to the inference cluster.

Confirm that the policy is active by running gcloud container binauthz policy export --project my-project and verifying that all three attestors appear under defaultAdmissionRule and that DRYRUN_AUDIT_LOG_ONLY is set for the dev cluster entry.

Do's and Don'ts

Now that you have worked through the implementation, the practices below separate a durable approach from a fragile one.

Do's

1. ✓Do set enforcementMode: DRYRUN_AUDIT_LOG_ONLY on dev clusters before promoting to ENFORCED_BLOCK_AND_AUDIT_LOG on production — reviewing Cloud Audit Logs for unexpected denials in the dev cluster reveals missing attestations before hard-blocking can disrupt inference workloads.
2. ✓Do require all three attestors (vulnerability-scan, model-provenance, and ai-bom-validation) under defaultAdmissionRule — omitting any one attestor leaves a gap through which images with unverified model weights or missing AI-BOMs can reach production unchecked.
3. ✓Do pass check=True to subprocess.run when importing the policy via gcloud container binauthz policy import`` — this raises CalledProcessError on a malformed YAML, preventing a broken policy from silently replacing a working one in your project.

Don'ts

1. ✗Don't omit admissionWhitelistPatterns for Google-managed system images — without exempting patterns like gcr.io/google-containers/*, Binary Authorization will block GKE's own node-level containers at admission, breaking cluster operations before any AI inference workload is even scheduled.
2. ✗Don't apply ENFORCED_BLOCK_AND_AUDIT_LOG to the inference cluster without first verifying all three attestors appear under defaultAdmissionRule via gcloud container binauthz policy export — skipping this confirmation means a mis-scoped clusterAdmissionRules entry can leave the production cluster enforcing fewer attestors than intended.
3. ✗Don't rely on a single clusterAdmissionRules entry to protect production while leaving defaultAdmissionRule permissive — any cluster not explicitly named in clusterAdmissionRules falls back to the default rule, so a permissive or missing defaultAdmissionRule creates an open path for new clusters added later.