Prepare and test your skills
Prepare and test your skills
Attestor configuration and cryptographic signing is the process that lets Binary Authorization (opens in a new tab) prove a required check was performed on a container image before deployment. An attestor represents a trusted authority, such as a security team or quality gate, and an attestation is a signed statement that a specific image digest passed that authority's requirements. At deploy time on Google Kubernetes Engine (GKE) and Cloud Run, Binary Authorization verifies the signatures and only allows the image to deploy when all required attestations verify successfully.
Attestors and attestations in the supply chain link a human or automated security gate to cryptography. Each attestor is associated with an Artifact Analysis note and one or more public keys, and the corresponding private key is used to sign attestations for container images. An attestation authorizes a specific immutable image digest, not a mutable tag, and a single attestation can authorize identical images stored in multiple locations such as Artifact Registry, Container Registry, or an external registry.
Attestations are only enforced when the Binary Authorization policy requires them. The policy administrator must configure the default rule or a cluster-specific rule to require attestations from named attestors, otherwise images can deploy without verification. A special built-by-cloud-build attestor can also require that only images built by Cloud Build (opens in a new tab) deploy, which connects build provenance directly to deployment enforcement.
Creating attestors with Cloud Key Management Service (Cloud KMS) keys establishes who is trusted to sign deployment approvals. An attestor is created after enabling Binary Authorization, using the Google Cloud console, Google Cloud CLI, or REST API. The attestor stores its identity in an attestor project and references a cryptographic public key whose private key is held either locally or in Cloud KMS. Using Cloud KMS keeps the private signing key inside Google's managed key service instead of on a developer workstation, which reduces exposure and supports central auditing and rotation. Key management with Cloud KMS supports separation of duties through project isolation. The attestor definition can live in an attestor project controlled by a security team, while attestations are stored as occurrences in a separate attestation project controlled by builders or quality teams. This separation means the team that defines who is trusted is different from the team that creates signed statements, so no single identity controls both sides of the trust boundary.
Signing container images to create attestations is the act of cryptographically signing an image digest with the attestor's private key. The signing workflow identifies the image as IMAGE_PATH@IMAGE_DIGEST, where the path includes the registry domain and image name and the digest is the manifest hash such as sha256:37e528.... Images are not accessed during attestation creation (opens in a new tab), so the path does not need to refer to a live image at signing time.
The signing identity must have Identity and Access Management permissions across the trust boundary. That identity needs roles/containeranalysis.notes.attacher on the note resource associated with the attestor and roles/containeranalysis.occurrences.editor on the attestation project where the signed occurrence will be stored. Without both permissions, the flow from signer to note to attestation project cannot complete. The end-to-end setup follows an ordered dependency:
build-secure or prod-qa, and attach its Cloud KMS public key and note.How Binary Authorization verifies signatures at deploy time determines whether a Pod or Cloud Run revision is admitted. When a workload requests an image by digest, Binary Authorization looks up attestations for that digest in the configured attestation projects and verifies each required attestor's signature using that attestor's public key material stored in Artifact Analysis. If every required signature verifies, deployment proceeds; if any required attestation is missing or invalid, deployment fails unless breakglass is explicitly used. The choice of signing key type affects security operations and compliance:
| Signing option | Where private key lives | Choose when |
|---|---|---|
| Locally stored key | On the signer workstation or build worker | The workflow is a small test or tutorial without central key control |
| Cloud KMS key | In Cloud KMS, referenced by key version and using algorithms such as ECDSA_P256_SHA256 | Production gates need central management, auditing, separation of duties, and protection from key exfiltration |
Exam tip: An attestation always signs the immutable image digest, not the tag, so the same attestation remains valid when the identical digest appears in different registries.
Implementing Binary Authorization enforcement policies controls which container images are allowed to run on Google Kubernetes Engine clusters and Cloud Run. A Binary Authorization (opens in a new tab) policy lives in one Google Cloud project and is enforced when a workload deploys to a cluster, even when the policy, the cluster, and the container images are owned by different projects. Enforcement depends on three projects working together, with cross-project access granted when those projects differ.
Policy, cluster, and artifact projects define where each part of Binary Authorization enforcement lives. The cluster project depends on the policy project for deployment decisions, and it depends on the artifact project for image data. The Binary Authorization service agent must be able to reach the policy and the image metadata in the source repository, so Identity and Access Management permissions must connect the service agent to resources outside its own project:
When cross-project access is required is determined by whether enforcement spans more than one Google Cloud project. Access is required when the policy project is different from the cluster project, because the cluster cannot evaluate its deployments without reading the policy from the other project. Access is also required when the cluster project is different from the artifact project, because the Binary Authorization service needs permission to read image metadata from the repository owned by the other project. In both cases, the enforcement check flows from the deployment request in the cluster project to policy evaluation in the policy project and to image metadata in the artifact project. If either permission path is missing, allowed images cannot be verified and deployments that depend on cross-project policy or images will fail enforcement.
Exam tip: Grant access when the policy project differs from the cluster project or when the cluster project differs from the artifact project; same-project policy, cluster, and images do not need this extra grant.
Preparing projects for Binary Authorization enforcement means selecting the projects and enabling the control plane that performs the checks. An operator creates or selects a Google Cloud project, confirms billing is enabled on that project, and enables the binaryauthorization.googleapis.com API. Project creation requires the Project Creator role, which contains the resourcemanager.projects.create permission, while enabling APIs requires the serviceusage.services.enable permission, typically available through the Owner or Service Usage Admin role.
The Google Cloud CLI is used to manage this setup through project creation, project selection, and API enablement. Keeping enforcement resources in a dedicated project makes cleanup simple, because deleting that project removes all associated resources. Once the API is enabled, the project can host a Binary Authorization policy and its service agent can be granted access to clusters and image repositories in other projects.
Analyzing the generation and storage of build provenance explains how verifiable build metadata moves from the builder to long-term storage and policy enforcement. Build provenance in Cloud Build (opens in a new tab) is verifiable, Supply-chain Levels for Software Artifacts (SLSA)-compliant metadata that describes how an artifact was built. Cloud Build generates this metadata automatically during a build, and the metadata flows from Cloud Build to the Artifact Analysis metadata store for long-term storage. Stored provenance can then be checked by Binary Authorization policies so only verified artifacts reach production.
Contents of Cloud Build provenance describe builder identity, build inputs, and build outputs that let a consumer verify an artifact. The provenance includes signed identities for the build service that executed the build, and Cloud Build can also be configured to record verifiable metadata about the service account used to initiate the build, such as when signing container images with cosign. The full provenance payload is stored as a base-64 encoded version of all provenance metadata, and dependencies declared in the build file are recorded in the resolvedDependencies field.
Provenance carries two builder signatures with different lifecycles. The current signature is recommended for new uses of provenance that will be verified in Binary Authorization policies, while the second signature with key name builtByGCB is provided for legacy usage. Because the signatures bind the artifact to the trusted builder rather than to an individual developer workstation, a deployment system can confirm that artifacts were generated from trusted sources and that the metadata describing the build process is complete and authentic.
Exam tip: Use the current Cloud Build signature for new Binary Authorization policies; the builtByGCB signature remains only for legacy usage.
Generation for non-container artifacts means Cloud Build creates SLSA provenance when standalone language applications are built and uploaded to Artifact Registry. Generation happens automatically as part of the Cloud Build run, so the developer only needs to run a supported build and note the resulting BuildID for later lookup. In each case, data flows from the Cloud Build job to Artifact Registry as the artifact destination, and provenance describing that job flows from Cloud Build to Artifact Analysis as the metadata destination. The supported standalone artifact types are:
Storage and retrieval in Artifact Analysis keeps each build record as a BUILD kind occurrence that contains in-toto SLSA provenance. The occurrence links the artifact back to its exact build through the field build.inTotoSlsaProvenanceV1.predicate.runDetails.metadata.invocationId, whose value is the full Cloud Build resource name in the form https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/builds/BUILD_ID. This link depends on three identifiers: the Google Cloud project ID, the region where the build ran such as us-central1, and the BuildID from the completed build.
Retrieval from Artifact Analysis uses that link to find provenance for a specific build. First, the build runs in Cloud Build and produces the BuildID, then the user queries the metadata store by filtering for kind="BUILD" and the matching invocationId. Retrieval can use the gcloud container analysis occurrences list command or a direct call to the Container Analysis API, and both paths return the same BUILD occurrence records. Filtering on the nested invocationId field can be slower than filtering on top-level indexed fields, especially in projects with a very large number of occurrences.
roles/containeranalysis.notes.attacher on the attestor's note and roles/containeranalysis.occurrences.editor on the attestation project.BUILD occurrence linked by invocationId containing project ID, location, and BuildID.builtByGCB signature remains only for legacy usage.An attestor in Binary Authorization represents a trusted authority such as a security team or quality gate and is associated with an Artifact Analysis note and one or more public keys. An attestation is a signed statement using the corresponding private key that a specific immutable image digest passed that authority's requirements, and Binary Authorization verifies those signatures at deploy time to Google Kubernetes Engine (GKE) and Cloud Run before admitting the workload.
A Cloud Key Management Service key should be used when production gates need central management, auditing, separation of duties, and protection from key exfiltration because the private key stays inside Google's managed key service. A locally stored key where the private key lives on the signer workstation or build worker is for a small test or tutorial without central key control.
Cross-project access is required when the policy project is different from the cluster project because the cluster cannot evaluate its deployments without reading the policy from the other project. It is also required when the cluster project is different from the artifact project because the Binary Authorization service needs permission to read image metadata from the repository owned by the other project.
Cloud Build automatically generates Supply-chain Levels for Software Artifacts (SLSA) provenance and stores it in Artifact Analysis as a BUILD kind occurrence containing in-toto SLSA provenance. The occurrence links back to the exact build through invocationId containing the project ID, location, and BuildID, and it is retrieved by filtering for BUILD kind occurrences with the matching invocationId.
Last updated