Professional Cloud Developer
Prepare and test your skills
Prepare and test your skills
A process flow showing how Cloud Build generates provenance, signs it with Cloud KMS, stores it in Artifact Analysis, and Binary Authorization verifies the attestation before allowing deployment to GKE or Cloud Run.
Cloud Build takes source code and automatically creates container images using either a Dockerfile or buildpacks. Once created, these images must be stored in Artifact Registry, which serves as a secure, version-controlled repository. A critical first step is that you must create the target repository in Artifact Registry before you can push any images to it.
There are two main ways to store images during a build. The images field in your configuration file automatically uploads the image and displays it in your build results. Alternatively, you can use the docker push command as a specific step in your pipeline. Using both methods together provides the best visibility and tracking in the Google Cloud console.
Artifact Analysis provides automated vulnerability scanning to keep your containers secure. This "shifts left" security by catching issues early in development rather than at the end. You can configure your pipeline to block deployment if the scan detects any risks. There are two scan types: automatic scanning runs when images are pushed to a repository, and on-demand scanning lets you manually check images during the build process.
To make builds faster, use layer caching with the --cache-from argument, which reuses unchanged parts from previous builds. Adding a .gcloudignore file prevents unnecessary files from being uploaded, keeping builds lean. For additional security, Binary Authorization enforces policies that only allow signed and scanned images to be deployed, creating a secure chain of trust from build time to production.
A cloudbuild.yaml file defines a multi-step build process where each step runs inside a specialized container called a builder. For example, a step might use the docker builder to run a build command with specific arguments. This configuration gives developers fine-grained control over how applications are packaged.
You can start a build using the gcloud builds submit command from your local terminal or script. There are three ways to define how the image gets created: using a Dockerfile for custom environment instructions, using Cloud Buildpacks to create images automatically without a Dockerfile, or referencing a custom cloudbuild.yaml for complex multi-stage workflows. The choice depends on your application's complexity and how much control you need.
Substitution variables like $PROJECT_ID let you reuse the same build configuration across different projects and environments. These act as placeholders that Cloud Build fills in automatically. To fully automate the workflow, set up Build Triggers that start a build whenever code is updated in a repository, ensuring the latest code is always ready for deployment.
After the build finishes, the resulting image goes to a specific location in Artifact Registry. Including the images field in your config ensures the image is tracked and displayed on the build results page. While you can also use a docker push step, the images field provides better visibility in the Google Cloud console.
Artifact Registry stores your container images in a central, managed location. To automate a build, you use a build config file written in YAML or JSON that tells Cloud Build exactly what to do, such as using the Docker builder to create an image. Including substitutions like $PROJECT_ID makes your build files flexible across different environments, and adding the images field ensures Cloud Build knows to push the finished product to your repository.
Access control uses Identity and Access Management (IAM) to determine who can view or modify your files. When working across different projects, granting the Artifact Registry Writer role to the build service account is often necessary for successful automation.
Artifact Registry offers different repository modes to organize your work. Standard repositories store private container images and packages. Remote repositories act as a proxy to cache images from external sources. Virtual repositories group multiple repositories under a single address for easier access. Choosing the right mode helps optimize storage and maintain security compliance.
Artifact Analysis automatically performs vulnerability scanning on your images to find security risks before deployment. You can also set up cleanup policies to automatically remove old or unused images, which saves storage costs and keeps your environment organized. Together, these tools ensure your software supply chain remains safe and efficient.
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.
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.
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.
StudyCerts
StudyCerts