Cloud Build Execution Service Account

Secure Cloud Build Execution with Dedicated Service Accounts

Your enterprise is designing a secure Continuous Integration (CI) pipeline using Cloud Build triggered from a Secure Source Manager repository. The pipeline must fetch application dependencies, retrieve sensitive API keys from Secret Manager, build container images, push them to Artifact Registry, and create attestations for Binary Authorization. To enforce security compliance, your team must adhere strictly to the principle of least privilege for all service identities involved in build invocation and execution.

Which IAM role and identity configuration should you implement?

Assign the default Cloud Build Service Account the Project Editor role and grant the Secure Source Manager Service Agent the Secret Manager Admin role across the project.

Grant the Container Analysis Notes Editor role to the Cloud Build execution service account in the customer project and assign the Artifact Registry Reader role on the destination repository.

Generate a downloadable JSON service account key for a shared deployment service account, store the key file in the Git repository root, and grant the service account the Artifact Registry Administrator role.

Configure a user-managed service account for the repository with the Cloud Build Editor role and Service Account User role on a dedicated Cloud Build execution service account, and grant the Cloud Build execution service account the Secret Manager Secret Accessor role on the required secret along with the Artifact Registry Writer role.

Explanations

Assign the default Cloud Build Service Account the Project Editor role and grant the Secure Source Manager Service Agent the Secret Manager Admin role across the project.

What the option does

This configuration relies on the default Cloud Build service account and grants it coarse-grained administrative privileges (roles/editor) at the project level, while assigning the Secret Manager Admin role (roles/secretmanager.admin) to the Secure Source Manager Service Agent.

Why it doesn't meet the requirement

Violates Least Privilege: Assigning roles/editor grants broad edit access across almost all Google Cloud resources in the project, exceeding what a CI pipeline requires.
Excessive Secret Manager Permissions: The pipeline only needs read/access rights to specific secrets at build time (roles/secretmanager.secretAccessor), not full administrative authority to modify, create, or delete secret metadata (roles/secretmanager.admin).
Wrong Service Identity for Secrets: Secret Manager access is needed during build execution by the build agent, not by the source repository service agent.

Key limitations

Lacks isolation between separate repository pipelines.
Vastly increases the blast radius if build scripts are compromised.
Fails compliance audits that enforce least privilege and segregation of duties.

This answer would be correct if

You were running an unconstrained sandbox prototype where rapid prototyping took complete priority over security controls, IAM governance, and least-privilege compliance.

View source documentation

Grant the Container Analysis Notes Editor role to the Cloud Build execution service account in the customer project and assign the Artifact Registry Reader role on the destination repository.

What the option does

This configuration assigns the roles/containeranalysis.notesEditor role to the execution service account within the application (customer) project and grants read-only access (roles/artifactregistry.reader) to the target Artifact Registry repository.

Why it doesn't meet the requirement

Inadequate Registry Permissions: The CI pipeline is responsible for building and pushing new container images. The roles/artifactregistry.reader role only allows pulling images, which causes image push steps to fail.
Incorrect Metadata Role Mapping: Notes in Artifact Analysis represent high-level metadata schemas typically managed in a centralized provider project. Application build agents acting as customers attach occurrences and require occurrence creation permissions (roles/containeranalysis.occurrences.editor and roles/containeranalysis.notes.attacher), rather than provider note editing.
Missing Secret Access: It fails to configure access to Secret Manager credentials needed during the pipeline execution.

Key limitations

Build jobs will fail when attempting to upload built container images.
Does not provide access to secrets in Secret Manager.
Misconfigures provider and customer responsibilities for Artifact Analysis metadata.

This answer would be correct if

The service account was only intended to scan existing container images and generate new note schemas within a centralized security metadata provider project.

View source documentation

Generate a downloadable JSON service account key for a shared deployment service account, store the key file in the Git repository root, and grant the service account the Artifact Registry Administrator role.

What the option does

This pattern uses long-lived service account key credentials committed directly into version control, paired with full repository administrative privileges (roles/artifactregistry.admin).

Why it doesn't meet the requirement

Severe Security Vulnerability: Hardcoding or storing private service account keys in version control repositories risks immediate credential exfiltration and unauthorized access.
Directly Contradicts Best Practices: Best practices explicitly recommend avoiding downloadable service account keys in favor of native IAM impersonation, short-lived tokens, and Secret Manager.
Excessive Artifact Registry Privileges: Pushing build artifacts only requires roles/artifactregistry.writer, not full administrative capabilities over repository settings.

Key limitations

Vulnerable to automated secret scrapers and repository leaks.
Violates organization policy constraints such as iam.disableServiceAccountKeyCreation.
Key rotation and lifecycle management become manual and error-prone.

This answer would be correct if

There were no native Google Cloud IAM integration available between source control and build infrastructure, and an external system strictly required static key file authentication.

View source documentation

Configure a user-managed service account for the repository with the Cloud Build Editor role and Service Account User role on a dedicated Cloud Build execution service account, and grant the Cloud Build execution service account the Secret Manager Secret Accessor role on the required secret along with the Artifact Registry Writer role.

What the solution is

This configuration establishes a secure, least-privilege CI pipeline by separating the identity that triggers the build from the custom identity that executes the build steps. A user-managed repository service account handles build triggering, while a dedicated, user-specified Cloud Build service account carries out the actual build operations.

How it meets the requirements

Principle of Least Privilege: Instead of relying on broad project-wide default service accounts, this setup grants granular permissions strictly required for each stage.
Secret Management: Granting roles/secretmanager.secretAccessor directly to the custom Cloud Build execution service account allows the build steps to securely access required sensitive API credentials from Secret Manager without embedding keys into source code or environment variables.
Artifact Registry and Build Execution: Granting roles/artifactregistry.writer allows the build runner to push generated container images, while the user-managed repository service account uses roles/iam.serviceAccountUser and roles/cloudbuild.builds.editor to invoke builds securely.

Key advantages

Granular Isolation: Different repositories and build pipelines can use isolated custom service accounts, preventing credential leakage across workloads.
Auditability and Traceability: All actions in Secret Manager, Artifact Registry, and Cloud Build are logged against dedicated identities rather than shared defaults.
Compliance Alignment: Satisfies zero-trust and least-privilege organizational policies by avoiding persistent service account keys and excessive privileges.

Why this is optimal

This approach aligns with Google Cloud architecture best practices for securing CI/CD pipelines. It prevents privilege escalation by ensuring the repository service account only possesses rights to trigger builds and impersonate the designated execution account, while the execution account is constrained to access only the specific artifacts and secrets required for that application.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Secure Cloud Build Execution with Dedicated Service Accounts

Which IAM role and identity configuration should you implement?

Assign the default Cloud Build Service Account the Project Editor role and grant the Secure Source Manager Service Agent the Secret Manager Admin role across the project.

Grant the Container Analysis Notes Editor role to the Cloud Build execution service account in the customer project and assign the Artifact Registry Reader role on the destination repository.

Explanations

Assign the default Cloud Build Service Account the Project Editor role and grant the Secure Source Manager Service Agent the Secret Manager Admin role across the project.

What the option does

Why it doesn't meet the requirement

Violates Least Privilege: Assigning roles/editor grants broad edit access across almost all Google Cloud resources in the project, exceeding what a CI pipeline requires.
Excessive Secret Manager Permissions: The pipeline only needs read/access rights to specific secrets at build time (roles/secretmanager.secretAccessor), not full administrative authority to modify, create, or delete secret metadata (roles/secretmanager.admin).
Wrong Service Identity for Secrets: Secret Manager access is needed during build execution by the build agent, not by the source repository service agent.

Key limitations

Lacks isolation between separate repository pipelines.
Vastly increases the blast radius if build scripts are compromised.
Fails compliance audits that enforce least privilege and segregation of duties.

This answer would be correct if

You were running an unconstrained sandbox prototype where rapid prototyping took complete priority over security controls, IAM governance, and least-privilege compliance.

View source documentation

Grant the Container Analysis Notes Editor role to the Cloud Build execution service account in the customer project and assign the Artifact Registry Reader role on the destination repository.

What the option does

Why it doesn't meet the requirement

Inadequate Registry Permissions: The CI pipeline is responsible for building and pushing new container images. The roles/artifactregistry.reader role only allows pulling images, which causes image push steps to fail.
Incorrect Metadata Role Mapping: Notes in Artifact Analysis represent high-level metadata schemas typically managed in a centralized provider project. Application build agents acting as customers attach occurrences and require occurrence creation permissions (roles/containeranalysis.occurrences.editor and roles/containeranalysis.notes.attacher), rather than provider note editing.
Missing Secret Access: It fails to configure access to Secret Manager credentials needed during the pipeline execution.

Key limitations

Build jobs will fail when attempting to upload built container images.
Does not provide access to secrets in Secret Manager.
Misconfigures provider and customer responsibilities for Artifact Analysis metadata.

This answer would be correct if

The service account was only intended to scan existing container images and generate new note schemas within a centralized security metadata provider project.

View source documentation

Generate a downloadable JSON service account key for a shared deployment service account, store the key file in the Git repository root, and grant the service account the Artifact Registry Administrator role.

What the option does

This pattern uses long-lived service account key credentials committed directly into version control, paired with full repository administrative privileges (roles/artifactregistry.admin).

Why it doesn't meet the requirement

Severe Security Vulnerability: Hardcoding or storing private service account keys in version control repositories risks immediate credential exfiltration and unauthorized access.
Directly Contradicts Best Practices: Best practices explicitly recommend avoiding downloadable service account keys in favor of native IAM impersonation, short-lived tokens, and Secret Manager.
Excessive Artifact Registry Privileges: Pushing build artifacts only requires roles/artifactregistry.writer, not full administrative capabilities over repository settings.

Key limitations

Vulnerable to automated secret scrapers and repository leaks.
Violates organization policy constraints such as iam.disableServiceAccountKeyCreation.
Key rotation and lifecycle management become manual and error-prone.

This answer would be correct if

There were no native Google Cloud IAM integration available between source control and build infrastructure, and an external system strictly required static key file authentication.

View source documentation

Configure a user-managed service account for the repository with the Cloud Build Editor role and Service Account User role on a dedicated Cloud Build execution service account, and grant the Cloud Build execution service account the Secret Manager Secret Accessor role on the required secret along with the Artifact Registry Writer role.

What the solution is

How it meets the requirements

Principle of Least Privilege: Instead of relying on broad project-wide default service accounts, this setup grants granular permissions strictly required for each stage.
Secret Management: Granting roles/secretmanager.secretAccessor directly to the custom Cloud Build execution service account allows the build steps to securely access required sensitive API credentials from Secret Manager without embedding keys into source code or environment variables.
Artifact Registry and Build Execution: Granting roles/artifactregistry.writer allows the build runner to push generated container images, while the user-managed repository service account uses roles/iam.serviceAccountUser and roles/cloudbuild.builds.editor to invoke builds securely.

Key advantages

Granular Isolation: Different repositories and build pipelines can use isolated custom service accounts, preventing credential leakage across workloads.
Auditability and Traceability: All actions in Secret Manager, Artifact Registry, and Cloud Build are logged against dedicated identities rather than shared defaults.
Compliance Alignment: Satisfies zero-trust and least-privilege organizational policies by avoiding persistent service account keys and excessive privileges.

Why this is optimal

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Secure Cloud Build Execution with Dedicated Service Accounts

Explanations

Assign the default Cloud Build Service Account the Project Editor role and grant the Secure Source Manager Service Agent the Secret Manager Admin role across the project.

What the option does

Why it doesn't meet the requirement

Key limitations

This answer would be correct if

Grant the Container Analysis Notes Editor role to the Cloud Build execution service account in the customer project and assign the Artifact Registry Reader role on the destination repository.

What the option does

Why it doesn't meet the requirement

Key limitations

This answer would be correct if

Generate a downloadable JSON service account key for a shared deployment service account, store the key file in the Git repository root, and grant the service account the Artifact Registry Administrator role.

What the option does

Why it doesn't meet the requirement

Key limitations

This answer would be correct if

What the solution is

How it meets the requirements

Key advantages

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

Cloud Build Webhook Trigger Payload Bindings

Cloud Build User-Defined Substitutions

IAM Deny Policy Overrides Allow

Cloud Monitoring Metrics Explorer Filtering and Aggregation

Binary Authorization and SLSA Provenance

BigQuery Reservations and Idle Slot Sharing

Secure Cloud Build Execution with Dedicated Service Accounts

Explanations

Assign the default Cloud Build Service Account the Project Editor role and grant the Secure Source Manager Service Agent the Secret Manager Admin role across the project.

What the option does

Why it doesn't meet the requirement

Key limitations

This answer would be correct if

Grant the Container Analysis Notes Editor role to the Cloud Build execution service account in the customer project and assign the Artifact Registry Reader role on the destination repository.

What the option does

Why it doesn't meet the requirement

Key limitations

This answer would be correct if

Generate a downloadable JSON service account key for a shared deployment service account, store the key file in the Git repository root, and grant the service account the Artifact Registry Administrator role.

What the option does

Why it doesn't meet the requirement

Key limitations

This answer would be correct if

What the solution is

How it meets the requirements

Key advantages

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

Cloud Build Webhook Trigger Payload Bindings

Cloud Build User-Defined Substitutions

IAM Deny Policy Overrides Allow

Cloud Monitoring Metrics Explorer Filtering and Aggregation

Binary Authorization and SLSA Provenance

BigQuery Reservations and Idle Slot Sharing