Binary Authorization and Artifact Security

Introduction to Supply Chain Security

As organizations move toward containerized workloads, securing the software supply chain becomes critical. It's not enough to secure the runtime environment; you must also ensure that only trusted, verified code is allowed to run.

Binary Authorization and Artifact Registry work together to provide a robust defense-in-depth strategy for your container deployments in GKE and Cloud Run.

白話文解釋（Plain English Explanation）

Analogy 1: The Nightclub Bouncer with a Guest List

Think of Binary Authorization as a strict bouncer at the door of your GKE cluster. The container image is the guest trying to get in. The Attestor is the doorman's checklist — only guests whose names (image digests) have been signed off on the list by trusted verifiers (the security team, the CI pipeline, the QA lead) get in. The Attestation itself is the wristband: a cryptographic signature created with Cloud KMS that proves the image passed a specific gate. No wristband, no entry — even if the image was already running yesterday. Continuous Validation is the bouncer doing a re-check every hour to make sure nobody snuck in through a back door.

Analogy 2: The Customs Officer at the Airport

Artifact Registry vulnerability scanning is like customs at an international airport. Every container (suitcase) that arrives gets X-rayed for known threats (CVEs from the OSV database). Automatic scanning happens on push (declared on arrival), while continuous analysis keeps re-checking stored bags as new threat intelligence comes out — a CVE published next week against a base layer pushed today will surface retroactively. Remote Repositories act like a duty-free transit zone: external images (Docker Hub) are cached and scanned by Google Cloud before any of your workloads pull them, so you never expose production directly to the public internet.

Analogy 3: A Notary and the Apostille Stamp

The cosign + Sigstore signing workflow is like getting a document notarized for international use. The developer signs the image with a private key (cosign sign), the notary's stamp (the signature stored in the OCI registry next to the image) proves the document was real at signing time, and Binary Authorization is the foreign embassy that refuses to accept any document without that stamp. Dry-run mode is the rehearsal: the embassy logs every document it would have rejected but lets everything through, so you can audit before turning enforcement on.

Artifact Registry: Hardening the Source

Artifact Registry is the evolution of Container Registry, providing a secure place to store and manage your build artifacts.

1. Vulnerability Scanning

• Automatic Scanning: Every time an image is pushed, Artifact Registry can scan it for known vulnerabilities (CVEs).
• On-demand Scanning: Allows you to scan local images before they are pushed or scan existing images in the registry.
• Continuous Analysis: Monitoring for new vulnerabilities that are discovered after an image has been stored.

2. IAM and Hardening

• Repository Isolation: Create separate repositories for different teams or environments (Dev/Prod).
• Cleanup Policies: Automatically delete old or vulnerable images to reduce the attack surface.
• VPC-SC Integration: Ensure that images can only be pushed or pulled from within a trusted network.

Binary Authorization: Enforcing Trust

Binary Authorization is a deploy-time security control that ensures only trusted container images are deployed on Google Kubernetes Engine (GKE) or Cloud Run.

How it Works:

1. Policy: You define a policy that specifies the requirements for deployment (e.g., "Allow all," "Disallow all," or "Require Attestations").
2. Attestors: An entity (like a build system or a security scanner) that "signs off" on an image.
3. Attestations: A digital signature created by an attestor, certifying that an image has met specific criteria (e.g., passed vulnerability scans).
4. Enforcement: When a deployment request is made, Binary Authorization checks the image against the policy. If the requirements (signatures) aren't met, the deployment is blocked.

The Attestation Workflow

1. Build: Cloud Build builds the container image and pushes it to Artifact Registry.
2. Scan: Artifact Registry scans for vulnerabilities.
3. Sign: If the scan is clean, a Kritis Signer or a custom script creates an attestation using Cloud KMS.
4. Verify: Binary Authorization verifies the signature against the public key stored in the Attestor.

Advanced Security Patterns

1. Break-glass Procedures

In an emergency (e.g., a critical production fix), you might need to bypass Binary Authorization.

• Break-glass: A special annotation in the GKE deployment manifest that allows the image to run despite policy violations.
• Auditing: Every break-glass event is logged in Cloud Audit Logs for immediate review and justification.

2. SLSA (Supply-chain Levels for Software Artifacts)

SLSA is a security framework to prevent tampering and improve integrity.

• Google Cloud services like Cloud Build provide "Build Provenance," which helps you reach higher SLSA levels by proving where and how an image was built.

3. Remote Repositories and Caching

Artifact Registry supports Remote Repositories (e.g., caching Docker Hub).

• Security: This allows you to apply vulnerability scanning to external images and ensures availability if the external registry goes offline.

Auditing and Monitoring

• Deployment Violations: Logged in the Binary Authorization audit logs.
• Dry Run Mode: Allows you to test your policy without actually blocking deployments, helping you identify what would have been blocked.

Attestors, KMS Keys, and Signed Payloads

A Binary Authorization Attestor is a Google Cloud resource that bundles three things: a Container Analysis Note (the "thing being attested to" — e.g. projects/my-proj/notes/vuln-scan-passed), a PKIX public key used to verify signatures, and an IAM allow list of which service accounts may create attestations against it. The private half of the keypair lives in Cloud KMS under an asymmetric signing key (algorithm EC_SIGN_P256_SHA256 or RSA_SIGN_PKCS1_4096_SHA512).

The signed payload format

The payload that gets signed is not the image bytes. It is a small JSON blob produced by gcloud container binauthz create-signature-payload, containing the fully-qualified image digest (gcr.io/proj/app@sha256:abcd…). This is critical because:

• Tag mutability is bypassed — signatures bind to immutable digests, so re-pushing :latest does not transfer trust.
• The payload itself can be re-verified offline by anyone with the public key.
• Cloud KMS performs the actual AsymmetricSign operation, so the private key never leaves the HSM.

Example creation flow

gcloud container binauthz create-signature-payload \
  --artifact-url="us-docker.pkg.dev/proj/repo/app@sha256:..." > payload.json

gcloud kms asymmetric-sign \
  --location=global --keyring=binauthz --key=prod-attestor \
  --version=1 --digest-algorithm=sha256 \
  --input-file=payload.json --signature-file=signature.bin

gcloud container binauthz attestations create \
  --artifact-url="us-docker.pkg.dev/proj/repo/app@sha256:..." \
  --attestor=projects/proj/attestors/prod-vuln-scan \
  --signature-file=signature.bin --pgp-key-fingerprint=...

Continuous Validation and Dry-Run Mode

Continuous Validation (CV) is the often-forgotten second half of Binary Authorization. Admission control only checks images at deploy time — but pods can run for weeks, and a policy may be tightened after the fact. CV periodically re-evaluates every running pod in every Binary-Authorization-enabled GKE cluster against the current policy and emits a Cloud Logging entry to the binaryauthorization.googleapis.com%2Fcontinuous_validation log when a running workload no longer satisfies the policy. CV runs roughly every 24 hours and does not evict pods — it is observe-only, so the SRE team gets time to remediate without surprise restarts.

Dry-run as the safe rollout pattern

Setting enforcementMode: DRYRUN_AUDIT_LOG_ONLY on either a cluster-specific rule or the default rule causes Binary Authorization to:

• Evaluate the policy as if it were enforcing.
• Log every would-be denial to binaryauthorization.googleapis.com%2Factivity with verdict: VIOLATES_POLICY.
• Admit the pod anyway.

This is the only safe way to introduce attestor requirements onto a cluster that already has hundreds of running workloads. Pair it with a Log Analytics query grouped by protoPayload.resourceName to enumerate which deployments would break before you flip to ENFORCED_BLOCK_AND_AUDIT_LOG.

Cosign, Sigstore, and Keyless Signing

While Binary Authorization's native attestor format is the canonical Google Cloud workflow, cosign (part of the Sigstore project) has become the de-facto open-source standard for container signing and is fully interoperable with Binary Authorization via the Sigstore Signature Format support added in 2023.

Three cosign modes worth knowing

• Key-based signing: cosign sign --key gcpkms://projects/p/locations/global/keyRings/r/cryptoKeys/k/cryptoKeyVersions/1 IMAGE — signs using a Cloud KMS-backed key. The signature is stored as an OCI artifact (sha256-...sig) next to the image in Artifact Registry.
• Keyless signing (OIDC): cosign sign IMAGE from inside Cloud Build uses the build's workload identity OIDC token to mint a short-lived certificate from Sigstore's Fulcio CA, and records the signature in the public Rekor transparency log. No long-lived keys to rotate.
• Attestations with predicates: cosign attest --predicate sbom.spdx.json --type spdxjson IMAGE attaches a structured in-toto attestation (e.g. an SBOM or SLSA provenance document) signed and verifiable the same way.

Wiring cosign into Binary Authorization

Configure the Binary Authorization attestor with the same public key cosign signs with (cosign public-key --key gcpkms://...), and Binary Authorization will accept cosign-generated signatures at admission. This is how teams standardize on a single signing tool across GKE, Cloud Run, on-prem Kubernetes, and ECR-hosted multi-cloud images.

PSE Exam Scenarios

Scenario 1: Preventing Deployment of Vulnerable Images

"A company wants to ensure that no container image with a 'Critical' or 'High' vulnerability score is ever deployed to their production GKE cluster. How do you implement this?" Answer: 1. Enable Vulnerability Scanning in Artifact Registry. 2. Use Cloud Build to trigger a scan. 3. Use an automated signer (like Kritis) to create an Attestation only if no High/Critical CVEs are found. 4. Configure a Binary Authorization Policy that requires this specific attestor for the production cluster.

Scenario 2: Emergency Fix

"A critical bug is found in production. The fix is ready, but the security scanner is currently down, so an attestation cannot be generated. How can the engineer deploy the fix?" Answer: Use the Break-glass procedure by adding the image-policy.k8s.io/break-glass: "true" annotation to the pod specification. Ensure the event is audited and justified afterward.

Summary Checklist

• Describe the relationship between Artifact Registry and Binary Authorization.
• Explain how an Attestation is created and verified.
• Identify the role of Cloud KMS in the signing process.
• Contrast "Enforce" mode vs. "Dry Run" mode.
• Explain the purpose of a "Break-glass" deployment.
• Define the importance of SLSA in supply chain security.