GCP Service Account Impersonation Explained | Secure Short-Term Access

















Service account keys provide long lived access. One often has to provide short term access to GCP resources. That's what Service account impersonation does.

GCP Service Account Impersonation Explained

Service account keys provide long-lived credentials. Once downloaded, a key generally remains usable until it is deleted, disabled, or otherwise restricted. If the key is copied, exposed, or committed to a source-code repository, anyone possessing it may be able to authenticate as that service account.

Service account impersonation provides a safer alternative when a user or workload needs temporary access to Google Cloud resources. Instead of distributing a permanent private key, Google Cloud generates short-lived credentials for the service account. Google recommends using more secure alternatives to service account keys whenever possible.

How Service Account Impersonation Works

Service account impersonation involves two identities:

  1. Caller principal
    The identity requesting temporary credentials. This can be:

    • Another service account
    • A Google user account
    • In some architectures, a federated external identity
  2. Target service account
    The service account being impersonated. It has the IAM roles needed to access the required Google Cloud resources.

The caller does not permanently become the target service account. Instead, Google Cloud issues a short-lived token representing the target service account.

For example:

Caller:
[email protected]

Target service account:
[email protected]

Suppose storage-reader has the Storage Object Viewer role on a production bucket. The caller can use impersonation to obtain a temporary token for storage-reader and read objects from that bucket without possessing a service account key.

Required IAM Permissions

The caller normally requires the following role on the target service account:

Service Account Token Creator
roles/iam.serviceAccountTokenCreator

This role includes the iam.serviceAccounts.getAccessToken permission required to generate an access token.

The important distinction is:

Caller receives Token Creator on the target service account
Target service account receives access to the actual GCP resource

For example:

Identity Role Scope
application-sa Service Account Token Creator On storage-reader
storage-reader Storage Object Viewer On the production bucket

Giving the caller Token Creator does not directly grant it access to the bucket. It allows the caller to temporarily operate as storage-reader, which already has that access.

Configuring Impersonation in the Google Cloud Console

To allow one service account to impersonate another:

  1. Open the Google Cloud Console and go to IAM & Admin → Service Accounts.
  2. Select the project containing the target service account.
  3. Click the target—or privilege-bearing—service account, such as: 
    [email protected]
  4. Open the Permissions tab.
  5. Under Principals with access to this service account, click Grant Access.
  6. Enter the caller service account: 
    [email protected]
  7. Assign the following role: 
    Service Account Token Creator
roles/iam.serviceAccountTokenCreator
  8. Click Save.

These steps grant the role on the target service account—not broadly across the entire project. This narrower assignment better supports least privilege. See Google’s short-lived service account credentials documentation.

Equivalent gcloud Command

The same permission can be granted with the Google Cloud CLI:

gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --member="serviceAccount:[email protected]" \
  --role="roles/iam.serviceAccountTokenCreator"

Here:

  • storage-reader is the target service account.
  • application-sa is the caller service account.
  • The Token Creator role is assigned on storage-reader.

Using the Impersonated Identity

After the role is assigned, the caller can run a command using the target service account:

gcloud storage buckets list \
  --impersonate-service-account=storage-reader@my-project.iam.gserviceaccount.com

The Google Cloud CLI obtains short-lived credentials for storage-reader and uses its permissions to execute the command. No service account key needs to be downloaded or stored. Google documents this method in its service account impersonation guide.

To use impersonation for every subsequent gcloud command:

gcloud config set auth/impersonate_service_account \
  [email protected]

To stop using it:

gcloud config unset auth/impersonate_service_account

What If a User Wants to Impersonate a Service Account?

The pattern is essentially the same. The caller is a user account instead of another service account.

For example:

Caller user:
[email protected]

Target service account:
[email protected]

Grant the user the Service Account Token Creator role on the target service account:

gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --member="user:[email protected]" \
  --role="roles/iam.serviceAccountTokenCreator"

After signing in with the user account:

gcloud auth login

the user can run:

gcloud projects get-iam-policy my-production-project \
  --impersonate-service-account=production-auditor@my-project.iam.gserviceaccount.com

The command is executed using a short-lived credential for production-auditor, subject to that service account’s permissions.

This is useful when an administrator, developer, or auditor needs temporary elevated access without receiving a service account key or being granted permanent permissions directly.

Local Application Development Example

A developer can also create Application Default Credentials that use impersonation:

gcloud auth application-default login \
  --impersonate-service-account=application-runtime@my-project.iam.gserviceaccount.com

Supported Google Cloud client libraries can then use these credentials automatically. This lets locally running code behave like the production service account without storing its private key.

Security Benefits

Service account impersonation provides several advantages:

  • Credentials are short-lived.
  • No private service account key must be downloaded.
  • The caller and impersonated service account can generally both be identified in audit logs.
  • Access can be granted on one specific service account.
  • Removing the caller’s Token Creator role immediately prevents future impersonation.
  • The target service account’s permissions can be designed around a specific job function.

Example Use Cases

Production troubleshooting: A developer temporarily impersonates a read-only production diagnostic service account.

CI/CD deployment: A build service account impersonates a deployment service account with permissions to deploy Cloud Run services.

Cross-project access: A workload in one project impersonates a service account in another project to access a specific Cloud Storage bucket.

Security auditing: An auditor impersonates a service account with read-only access to IAM policies, logs, and security configurations.

Key Takeaway

Service account impersonation separates authentication from authorization:

The caller proves who it is.
The target service account defines what it can do.
Google Cloud issues temporary credentials connecting the two.

Whenever practical, use service account impersonation or another short-lived authentication mechanism instead of distributing long-lived service account keys.