Question

Difficulty: MediumConfiguring Service Account Impersonation and Workload Identity

A security engineer needs to enable a developer to manage Cloud Storage resources by impersonating a target service account from their local workstation using the Google Cloud CLI, without downloading long-lived service account keys. Arrange the steps required to configure and verify service account impersonation in the correct sequential order.

  1. 1Grant the developer's user principal the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) on the target service account.
  2. 2Authenticate the developer's local environment with user credentials by running `gcloud auth login`.
  3. 3Configure the local gcloud CLI property to specify the target service account by running `gcloud config set auth/impersonate_service_account TARGET_SERVICE_ACCOUNT_EMAIL`.
  4. 4Execute resource management commands such as `gcloud storage ls` to access resources using short-lived impersonation tokens.

Answer

The correct procedure begins by granting the developer the Service Account Token Creator role on the target service account. Next, the developer authenticates their user identity locally using `gcloud auth login`. Then, the developer sets the `auth/impersonate_service_account` CLI property. Finally, the developer runs resource management commands using automatically generated short-lived tokens.
To establish service account impersonation for local gcloud CLI operations, administrative permissions (`roles/iam.serviceAccountTokenCreator`) must first be granted to the developer on the target service account. The developer then authenticates locally using their user identity via `gcloud auth login`. Following successful login, the developer configures gcloud CLI to impersonate the service account using `gcloud config set auth/impersonate_service_account`. Finally, running GCP commands seamlessly uses short-lived tokens minted on demand.

Step-by-Step Solution

1
Grant `roles/iam.serviceAccountTokenCreator` on the target service account to the developer's user identity.
The developer gains authorization to create short-lived OAuth 2.0 access tokens for the service account.
Service account impersonation requires explicit IAM authorization on the service account resource before short-lived token generation is allowed.
2
Execute `gcloud auth login` on the local workstation.
The developer authenticates and stores local user credentials in gcloud CLI.
The gcloud CLI relies on an authenticated user identity to issue Google Cloud IAM credentials API calls.
3
Execute `gcloud config set auth/impersonate_service_account TARGET_SERVICE_ACCOUNT_EMAIL`.
The gcloud CLI updates its active configuration profile to append impersonation parameters.
Setting this configuration tells gcloud CLI to request short-lived tokens for the target service account rather than invoking APIs under the user's base identity.
4
Execute GCP commands such as `gcloud storage ls`.
The storage resources are listed under the context and permissions of the target service account.
With configuration complete, commands transparently fetch short-lived tokens and perform operations under the delegated service account identity.

Key Concept

Configuring Service Account Impersonation via Google Cloud CLI
Rate this question