Question

Difficulty: Very hardConfiguring Service Account Impersonation and Workload Identity

An organization uses an automated CI/CD build pipeline running inside a central management project (`ci-build-proj`). The build process executes under a dedicated service account `[email protected]`. During the deployment phase, this pipeline must provision resources in a production project (`prod-scope-proj`) using a production service account `[email protected]`. Corporate security policies mandate that no service account keys can be exported or stored. Which IAM configuration correctly enables `ci-runner` to generate short-lived credentials to act as `prod-deployer` while strictly following the principle of least privilege?

  1. Grant `[email protected]` the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) directly on the `[email protected]` service account resource.Answer
  2. B
    Generate a service account JSON key for `[email protected]` and store it securely in the build system's secret storage.
  3. C
    Grant `[email protected]` the Service Account User role (`roles/iam.serviceAccountUser`) and Project Editor role (`roles/editor`) at the `prod-scope-proj` project level.
  4. D
    Grant `[email protected]` the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) directly on the `[email protected]` service account resource.

Answer

Grant `[email protected]` the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) directly on the `[email protected]` service account resource.
To enable short-lived credentials and service account impersonation without key exports, the executing principal (the build runner service account) must be granted the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) directly on the target service account's IAM resource policy.

Step-by-Step Solution

1
Identify the source identity attempting impersonation and the target identity being impersonated.
Source identity: `[email protected]`. Target identity: `[email protected]`.
IAM role bindings for impersonation must be placed on the target service account resource granting access to the source principal.
2
Determine the required predefined IAM role for generating short-lived OAuth tokens.
The `roles/iam.serviceAccountTokenCreator` (Service Account Token Creator) role provides the required permissions to mint short-lived credentials.
`roles/iam.serviceAccountUser` only allows attaching a service account to a GCP workload, whereas creating tokens to act as the service account requires `roles/iam.serviceAccountTokenCreator`.
3
Apply the principle of least privilege by scoping the binding to the target service account resource.
The IAM policy binding is applied directly to `[email protected]` rather than at the project level.
Scoping access to the specific service account resource prevents granting unnecessary permissions over other service accounts in the project.

Key Concept

Service Account Impersonation via Service Account Token Creator
Rate this question