Professional Cloud Developer

Evaluate Attestor Configuration and Cryptographic Signing

Build provenance is a collection of verifiable data about a build, such as the source location, build toolchain, and duration. Cloud Build generates this metadata so that organizations can confirm artifacts come from a trusted system rather than an untrusted source. Using provenance data prevents the deployment of code that has been tampered with and is a key part of reaching higher SLSA levels, which are security standards for the software supply chain.

An attestor is a security resource used by Binary Authorization to verify that a container image is ready for deployment. When a build completes successfully, an attestation is created, which acts as a digital signature for the image. The attestor checks this signature before allowing the image to run on platforms like GKE or Cloud Run, ensuring every image meets specific security gates and build-time requirements.

To sign images, developers use Cloud KMS to manage cryptographic keys. These keys digitally sign the build metadata, guaranteeing its integrity and authenticity. The attestor stores the public key needed to verify these signatures during deployment, so unauthorized parties cannot modify build artifacts or provenance data without detection.

Configuring this system requires specific settings in the build configuration file. For example, when using private pools, you must set requestedVerifyOption to VERIFIED to trigger provenance generation. After configuration, you can use gcloud commands or API calls to view the attestor’s metadata, including the attestor ID, public keys, and signature algorithm. In a multi-project setup, you must carefully manage IAM roles to allow secure communication between projects. The project deploying the image needs the attestorsVerifier role to access the attestor stored in a separate security project, following the principle of least privilege and defending against supply chain attacks.

Implement Binary Authorization Enforcement Policies

Binary Authorization is a security service that ensures only trusted container images are deployed to production. It works with Google Kubernetes Engine (GKE) and Cloud Run to enforce strict rules during deployment, creating a secure software supply chain that prevents unauthorized code from running. This process relies on provenance, which tracks the origin and build history of an artifact.

A Binary Authorization policy is a set of rules that governs how images are deployed. These policies can be configured using the Google Cloud Console or the Command Line Interface (CLI). Teams can choose from several enforcement levels: allow all images, deny all images, or require attestations (only images with valid digital signatures). This flexibility allows teams to tailor security to their specific environment needs.

To verify an image, the system uses attestors and attestations. An attestor is a person or process that confirms an image is ready, while an attestation is the digital signature they provide. Cloud Build can automatically create these records to prove the image’s provenance during the build process. Asymmetric PKIX keys are often used to verify the identity of these attestors, and deployment is blocked if required signatures are missing.

Before fully enforcing a policy, teams can use dryrun mode, a testing state that allows non-compliant images to be deployed while logging violations for review. This helps teams see how a policy affects production without causing downtime. Additionally, Continuous Validation monitors images even after deployment to ensure they remain compliant.

In some cases, urgent fixes require a break-glass exception, an emergency procedure that allows a user to bypass deployment rules to solve a critical issue quickly. Every break-glass event is recorded in the audit logs, ensuring that even emergency actions are transparent and can later be reviewed by security teams.

Analyze the Generation and Storage of Build Provenance

Build provenance is a digital record that describes exactly how a software artifact was created. It acts as verifiable proof that the code was built by a trusted process such as Cloud Build, rather than an unknown or malicious source. By documenting the source code, build steps, and environment, organizations maintain a secure software supply chain from start to finish.

To achieve high security, builds should be SLSA-compliant, referring to the Supply-chain Levels for Software Artifacts framework. This framework ensures that build metadata is tamper-proof and generated automatically during the build process. The metadata includes critical details like the unique build ID and the specific container image digest, which are essential for verifying software integrity.

Once a build is finished, the provenance information is automatically saved in the Artifact Analysis metadata store. This metadata store serves as a central location where security tools can check the history and origin of a container image. Storing these records allows for automated auditing and ensures every artifact can be tracked back to its specific build instructions and source code.

Binary Authorization and Policy Controller work together to enforce security by checking these build records before any code is deployed. These tools can deny the deployment of any images that do not come from trusted repositories or lack valid provenance. This ensures only verified artifacts run in production, which helps prevent misconfiguration, restrict access to authorized images, and defend against attacks by blocking unverified code.

Administrators can further protect the environment by using VPC Service Controls to define a security perimeter around services. This service helps restrict services from accessing outside resources and prevents external attackers from reaching sensitive data. By combining build provenance with these network controls, organizations defend against data exfiltration and maintain a robust security posture for their automated pipelines.