Study guide
12.3 Attestors, Policy Enforcement, and Break-glass
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
12.3 Attestors, Policy Enforcement, and Break-glass
Key Takeaways Explain This Topic AI
Attestors associate verification keys with attestation authorities and image-digest evidence.
Cloud KMS protection can be software or explicitly HSM-backed; asymmetric rotation requires trust updates.
Scanning does not automatically block deployment; the pipeline and admission policy must enforce the intended checks.
Last updated: October 2026
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:
Evaluation Mode Enforcement Behavior Cloud Audit Logging Primary Operational Use Case
Dry-Run Mode ( DRYRUN_AUDIT_LOG_ONLY ) Does NOT block deployments; non-compliant images are admitted and allowed to run Logs a non-compliance violation event to Cloud Audit Logs Testing new policies, auditing existing clusters, and identifying un-attested legacy images without production disruption
Enforce Mode ( ENFORCING ) Strictly BLOCKS non-compliant deployments; returns HTTP 403 Forbidden to the deployer Logs admission rejection and violation events to Cloud Audit Logs Production environments requiring strict compliance and zero-trust supply chain guarantees
- 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:
When the admission controller encounters image-policy.k8s.io/break-glass: "true" , it allows the pod to be scheduled regardless of missing attestations.
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.
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:
Commit: Developer pushes code to GitHub; a webhook triggers Cloud Build.
Isolated Build: Cloud Build compiles the application inside an ephemeral container, runs unit tests in parallel ( waitFor: ['-'] ), and outputs a container image.
SLSA Provenance: Cloud Build produces SLSA Level 3 non-falsifiable provenance and pushes the image to Artifact Registry.
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.
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.
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.