Lesson 10 · Security, supply chain & operations

Binary authorization & supply chain

Only run images your pipeline built — the "boarding pass" model, and why this repo's is stamped-but-not-checked.

Your win: explain supply-chain security via attestation and admission control, and read this repo's binary-authorization setup — including the honest fact that it's currently audit-only.

The threat: a rogue image runs in prod

Your cluster pulls images by name. What stops someone deploying an image that didn't come from the trusted pipeline — one built on a laptop, or tampered with? Nothing, by default. Binary Authorization is GCP's answer: admission control that only lets images with valid attestations run on GKE.1

Attestation = a boarding pass for an image An attestation is a cryptographic signature saying "this exact image passed this required step" (built by the trusted pipeline, scanned, QA'd). Each pipeline stage signs with a private key; at deploy, admission control verifies the signatures with the public key. No valid attestation → the image is refused. It's a boarding pass: you can't board (run) without one.1

This repo's supply chain

Anchor — the pipeline signs (build side) Right after the image is built and scanned (Lesson 5), the .github/actions/binauthz-sign/action.yml action runs gcloud beta container binauthz attestations sign-and-create (:88-95) against a KMS attestor (stag-deploy or prod-deploy, keyring binauthz-attestors). So every image the pipeline builds gets a signed attestation. This is GCP Binary Authorization, not cosign/Sigstore — worth naming precisely (both do image signing; different tools).
Anchor — the policy lives in Terraform The enforcement side is infrastructure, not CI: the module deployments/terraform/modules/binary-authorization-attestor/policy.tf defines a google_binary_authorization_policy with cluster_admission_rules + require_attestations_by, and GKE clusters enable it (enable_binary_authorization). You'll meet Terraform properly in Course 7 — here, note that the policy is code too.
The honest part: it's audit-only right now Attestations are created and signed — but the policy does not block deploys yet. Every admission rule is evaluation_mode = "ALWAYS_ALLOW", enforcement_mode = "DRYRUN_AUDIT_LOG_ONLY" (terraform/live/stag-manabie/…/terragrunt.hcl:49-50, and the prod cells). So an image without an attestation would still be admitted — the policy just logs what it would have done. This is the same "machinery built, enforcement not turned on" pattern as Istio's mTLS (Course 4 L9). The precise interview line: "We sign attestations and run Binary Authorization in DRYRUN — auditing, not blocking — so we can validate the policy before flipping it to enforce." That's exactly the safe way to roll out an admission gate.
Where SLSA fits This attestation-based provenance is the core idea behind SLSA (Supply-chain Levels for Software Artifacts): prove an artifact was built by a trusted, tamper-resistant pipeline. Signing every build is a concrete step up the SLSA ladder — even before enforcement is on.
Read this next

GCP Binary Authorization + SLSA

The attestation/admission model, DRYRUN vs enforce, and the supply-chain framework.

→ cloud.google.com — Binary Authorization overview
→ slsa.dev — Supply-chain Levels for Software Artifacts

Check yourself (from memory)

Q1. An attestation is…

A cryptographic "boarding pass": this image was built/scanned by the trusted pipeline. Verified at admission.

Q2. Binary Authorization enforces at…

It's GKE admission control: no valid attestation → the pod is refused (when enforced).

Q3. In this repo, Binary Authorization is currently…

DRYRUN_AUDIT_LOG_ONLY — attestations are signed and logged, but an unattested image is still admitted.
Supply-chain security — attestation, admission, and this repo's status.
recall, then click to reveal
THREAT: a rogue/tampered image runs in prod. BINARY AUTHORIZATION = GCP admission control that only runs images with valid ATTESTATIONS. ATTESTATION = a cryptographic "boarding pass" — a signature that this exact image passed a required step (built by the trusted pipeline, scanned); signed with a private key, verified at admission with the public key. REPO: build side SIGNS — binauthz-sign action runs gcloud … binauthz attestations sign-and-create (KMS attestor stag/prod-deploy) after build+scan. Policy is in TERRAFORM (google_binary_authorization_policy, cluster_admission_rules; GKE enable_binary_authorization). BUT it's AUDIT-ONLY: enforcement_mode = "DRYRUN_AUDIT_LOG_ONLY", evaluation_mode = "ALWAYS_ALLOW" → logs, doesn't block (like Istio mTLS-off). GCP attestors, NOT cosign. This is the SLSA provenance idea. Safe rollout = DRYRUN first, then enforce.
Want to see what flipping DRYRUN → enforce would take, or how cosign differs from GCP attestors? Ask me.

1. GCP — Binary Authorization overview.