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:
- To learn how to let a user manage or impersonate a single service account, see Manage access to service accounts.
- To learn how to let a user manage or impersonate all service accounts in your project, see Manage access to projects, folders, and organizations.
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 tokensiam.serviceAccounts.getOpenIdToken: lets you create OpenID Connect (OIDC) ID tokensiam.serviceAccounts.implicitDelegation: lets service accounts get tokens in a delegation chainiam.serviceAccounts.signBlob: lets you sign binary blobsiam.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 tokensiam.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:
- 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
Permissions:
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.serviceAccounts.implicitDelegation
Roles:
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
Permissions:
iam.serviceAccounts.getOpenIdToken
Roles:
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 (accounts.google.com) 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
Permissions:
iam.serviceAccountKeys.create
Roles:
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