Roles for managing and impersonating service accounts

Stay organized with collections Save and categorize content based on your preferences.

Service accounts are both identities and resources. Because service accounts are resources that accept allow policies, you can let other principals access service accounts by granting them roles on a service account.

This page lists the roles you can grant to principals to let them create, manage, or impersonate service accounts. Managing service accounts involves actions like viewing, updating, deleting, disabling, enabling, and listing service accounts, as well as managing their IAM policies. Impersonating service accounts is when a user uses short-lived credentials to authenticate as a service account. It's typically used to temporarily get elevated access. To learn more about service account impersonation, see Service account impersonation.

This page also describes the permissions you need to work with service accounts in certain common scenarios.

Service account roles

You can grant the following roles to principals to let them manage or impersonate service accounts.

To learn how to grant these roles to a user, see the following:

Service Account User role

The Service Account User role (roles/iam.serviceAccountUser) includes the iam.serviceAccounts.actAs permission, which allows principals to indirectly access all the resources that the service account can access. For example, if a principal has the Service Account User role on a service account, and the service account has the Cloud SQL Admin role (roles/cloudsql.admin) on the project, then the principal can impersonate the service account to create a Cloud SQL instance.

This role also allows principals to attach a service account to a resource.

This role does not allow principals to create short-lived credentials for service accounts, or to use the --impersonate-service-account flag for the Google Cloud CLI. To complete these tasks, you also need the Service Account Token Creator role.

Service Account Token Creator role

This role lets principals impersonate service accounts to do the following:

  • Create OAuth 2.0 access tokens, which you can use to authenticate with Google APIs
  • Create OpenID Connect (OIDC) ID tokens
  • Sign JSON Web Tokens (JWTs) and binary blobs so that they can be used for authentication

See Creating short-lived service account credentials for details.

The role's permissions include the following:

  • iam.serviceAccounts.getAccessToken: lets you create OAuth 2.0 access tokens
  • iam.serviceAccounts.getOpenIdToken: lets you create OpenID Connect (OIDC) ID tokens
  • iam.serviceAccounts.implicitDelegation: lets service accounts get tokens in a delegation chain
  • iam.serviceAccounts.signBlob: lets you sign binary blobs
  • iam.serviceAccounts.signJwt: lets you sign JWTs

Workload Identity User role

This role lets principals impersonate service accounts from GKE workloads.

The role's permissions include the following:

  • iam.serviceAccounts.getAccessToken: lets you create OAuth 2.0 access tokens
  • iam.serviceAccounts.getOpenIdToken: lets you create OpenID Connect (OIDC) ID tokens

Service account permissions for common scenarios

Service accounts can be used in many different scenarios, and each of them requires certain permissions. This section describes common scenarios and what permissions are required.

Attaching service accounts to resources

If you want to start a long-running job that authenticates as a service account, you need to attach a service account to the resource that will run the job.


  • Permissions to create the resource
  • iam.serviceAccounts.actAs

To find roles that include these permissions, search the roles list for the permissions.

There are several different Google Cloud resources that can run long-running jobs as service accounts. Some examples of these resources include:

  • Compute Engine VMs
  • App Engine apps
  • Cloud Functions

When you create these resources, you have the option to attach a service account. This service account acts as the resource's identity.

To create a resource and attach a service account, you need permissions to create that resource and permission to impersonate the service account that you will attach to the resource. Permission to impersonate the service account is provided by any role that includes the iam.serviceAccounts.actAs permission.

After you create the resource and attach a service account to it, you can start a long-running job on the resource. The job runs as the service account that is attached to the resource, and uses that service account to authorize requests to Google Cloud APIs.

To learn more about attaching service accounts to resources, see Attaching a service account to a resource.

Directly impersonating a service account


  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccounts.implicitDelegation


  • roles/iam.serviceAccountTokenCreator (Service Account Token Creator)

Once granted the required permissions, a user (or service) can directly impersonate (or assert) the identity of a service account in a few common scenarios.

First, the user may get short-term credentials for the service account using the iam.serviceAccounts.getAccessToken permission and by calling the generateAccessToken() method. By using short-term credentials, a user can issue commands to Google Cloud and can access all resources to which the service account has access. For example, this flow allows a user to use the gcloud --impersonate-service-account flag to impersonate the service account without requiring the use of a downloaded external service account key.

Second, the user may get artifacts signed by the Google-managed private key of the service account using the iam.serviceAccounts.signBlob permission and by calling either the signBlob() or signJwt() method. The Google-managed private key is always held in escrow and is never directly exposed. signBlob() allows signing of arbitrary payloads (such as Cloud Storage-signed URLs), while signJwt() only allows signing well-formed JWTs.

Finally, the user may impersonate (or assert) the service account without ever retrieving a credential for the service account. This is an advanced use case, and is only supported for programmatic access using the generateAccessToken() method. In scenarios with at least 3 service accounts, namely A, B, and C: service account A can get an access token for service account C if service account A is granted the iam.serviceAccounts.implicitDelegation permission on B, and B is granted the iam.serviceAccounts.getAccessToken permission on C.

Generating OpenID Connect (OIDC) ID tokens


  • iam.serviceAccounts.getOpenIdToken


  • roles/iam.serviceAccountTokenCreator (Service Account Token Creator)

A user (or service) can generate an OpenID Connect (OIDC)-compatible JWT token signed by the Google OIDC Provider ( that represents the identity of the service account using the iam.serviceAccounts.getOpenIdToken permission.

These tokens are not directly accepted by most Google APIs without your organization deploying additional identity federation to grant access to Google. There are a few exceptions—for example, Identity-Aware Proxy, which allows OIDC-based access to user-run applications.

Generating external private keys


  • iam.serviceAccountKeys.create


  • roles/editor (Editor)
  • roles/iam.serviceAccountKeyAdmin (Service Account Key Admin)

A user or service can generate external private key material (RSA) that can be used to authenticate directly to Google as the service account. This key material can then be used with Application Default Credentials (ADC) libraries, or with the gcloud auth activate-service-account command. Any person who gains access to the key material will then have full access to all resources to which the service account has access. Such private key material should be treated with the highest concern, and should be considered less secure the longer the material exists. Therefore, rotating private key material is critical to maintaining strong security.

Best practices for granting roles on service accounts

In scenarios where a service account has been granted permissions to perform highly-privileged operations, be cautious when granting the Service Account User role to a user on that service account.

Service accounts represent your service-level security. The security of the service is determined by the people who have IAM roles to manage and use the service accounts, and people who hold service account keys for those service accounts. Best practices to ensure security include the following:

  • Use the IAM API to audit the service accounts, the keys, and the allow policies on those service accounts.
  • If your service accounts don't need service account keys, disable or delete them.
  • If users don't need permission to manage or use service accounts, then remove them from the applicable allow policy.
  • Make sure that service accounts have the fewest permissions possible. Use default service accounts with caution, because they are automatically granted the Editor (roles/editor) role on the project.

To learn more about best practices, see Best practices for working with service accounts.

Try it for yourself

If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Get started for free