12.3 Attestors, Policy Enforcement, and Break-glass

Core Policy Primitives: Attestors, Notes, and Keys

Configuring Binary Authorization requires understanding four interlocking architectural components:

Attestor

An Attestor is a named Google Cloud resource representing a verification authority. For example, an organization might configure three independent Attestors:

• build-attestor: Confirms the image was compiled by the approved Cloud Build pipeline.
• security-scan-attestor: Confirms the image has zero CRITICAL or HIGH vulnerabilities in Container Analysis.
• qa-signoff-attestor: Confirms manual QA testing was completed.

Container Analysis Note

Each Attestor is linked to a specific Container Analysis Note of type ATTESTATION_AUTHORITY (e.g., projects/[PROJECT_ID]/notes/security-scan-note). The Note defines the schema and metadata anchor for attestations.

Cryptographic Keys in Cloud KMS

Attestors verify signatures using public/private key pairs. For controlled signing, the private signing key is stored in Cloud Key Management Service (Cloud KMS) as an asymmetric signing key (such as RSA_SIGN_PSS_2048_SHA256 or EC_SIGN_P256_SHA256).

• Cloud KMS manages non-exportable key material; choose HSM protection explicitly when required, because software-protected keys are also available.
• The Attestor resource stores only the Public Key.
• During deployment, Binary Authorization uses the Attestor's registered public key to verify that the attestation payload was indeed signed by the corresponding Cloud KMS private key.

Attestation Occurrence

When a pipeline step verifies an image, it constructs an attestation payload containing the image's SHA256 digest, calls Cloud KMS to sign the payload, and writes the resulting signature as a Container Analysis Occurrence linked to the Attestor's Note.

## Creating an attestation using Cloud KMS and Container Analysis
gcloud beta container binauthz attestations sign-and-create \
    --artifact-url=us-central1-docker.pkg.dev/my-project/apps/order-service@sha256:7a8b9c... \
    --attestor=projects/my-project/attestors/security-scan-attestor \
    --attestor-project=my-project \
    --keyversion-project=my-project \
    --keyversion-location=us-central1 \
    --keyversion-keyring=binauth-keyring \
    --keyversion-key=attestor-key \
    --keyversion=1

---

Policy Structure and Evaluation Modes

A Binary Authorization policy is a declarative specification defined at the project or cluster level.

Policy Rules

A policy defines a defaultAdmissionRule and optional cluster-specific or service-specific override rules. Available evaluation behaviors include:

• ALWAYS_ALLOW: Permissive rule allowing all images to deploy without verification (typically used for non-production development clusters or Google-managed system images).
• ALWAYS_DENY: Blocks all container images from executing.
• REQUIRE_ATTESTATION: The core security mode. Mandates that the image manifest must have valid cryptographic attestations from one or more specified Attestors before admission.

Evaluation Modes: Dry-Run vs. Enforce

Rolling out Binary Authorization in enterprise environments carries risk: an overly aggressive policy can inadvertently block critical production microservices. Google Cloud provides two operational modes via the enforcementMode setting:

Example: Declarative Binary Authorization Policy

globalPolicyEvaluationMode: ENABLE
admissionWhitelistPatterns: []

defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCING
  requireAttestationsBy:
    - projects/my-project/attestors/build-attestor
    - projects/my-project/attestors/security-scan-attestor

clusterAdmissionRules:
  # Staging cluster runs in Dry-Run mode to audit images
  us-central1.staging-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: DRYRUN_AUDIT_LOG_ONLY
    requireAttestationsBy:
      - projects/my-project/attestors/build-attestor

---

Emergency Break-Glass Overrides and Auditing

An organization can authorize an audited emergency exception under its incident policy. For example, if a severe zero-day outage strikes production and the automated CI/CD signing pipeline or Cloud KMS is impaired, an on-call site reliability engineer must be able to deploy an emergency hotfix without disabling the cluster's Binary Authorization infrastructure.

The Break-Glass Annotation

Binary Authorization supports an emergency override mechanism known as Break-Glass. An engineer can bypass attestation requirements by adding a specific annotation to the Kubernetes Pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: payment-emergency-patch
  annotations:
    # Emergency override annotation
    image-policy.k8s.io/break-glass: "true"
spec:
  containers:
  - name: payment-api
    image: us-central1-docker.pkg.dev/my-project/apps/payment-service:hotfix-v9

The Security Audit Trail

Break-glass is not a loophole; it is an auditable exception:

1. When the admission controller encounters image-policy.k8s.io/break-glass: "true", it allows the pod to be scheduled regardless of missing attestations.
2. Simultaneously, Binary Authorization generates a structured audit event in Cloud Audit Logs (cloudaudit.googleapis.com) recording:
   • The exact user identity (email or service account) who submitted the manifest.
   • The non-compliant image URI and SHA256 digest.
   • Timestamp, pod name, namespace, and cluster identity.
3. Security Operations (SecOps) teams configure Cloud Monitoring log-based alerts that trigger immediate high-priority PagerDuty incidents whenever a break-glass event is logged, initiating forensic review.

---

End-to-End Secure Pipeline Architecture

To pass the certification exam, synthesize how all continuous integration and supply chain security components interact:

1. Commit: Developer pushes code to GitHub; a webhook triggers Cloud Build.
2. Isolated Build: Cloud Build compiles the application inside an ephemeral container, runs unit tests in parallel (waitFor: ['-']), and outputs a container image.
3. SLSA Provenance: Cloud Build produces SLSA Level 3 non-falsifiable provenance and pushes the image to Artifact Registry.
4. Vulnerability Scanning: Container Analysis scans the image for vulnerabilities. The pipeline must explicitly wait for scan results, evaluate its severity/exception policy, and fail the build when that policy is violated. Scanning alone does not block deployment.
5. Attestation Signing: If the scan passes, a Cloud Build step calls Cloud KMS to sign the image digest and writes an Attestation Occurrence linked to the project's Attestor Note.
6. Deploy Interception: kubectl apply submits the workload to GKE. Binary Authorization intercepts the request, validates the signature against the Attestor's public key, and admits the container to run.