This page explains service accounts, types of service accounts, and the IAM roles that are available to service accounts.
Before you begin
- Understand the basic concepts of IAM.
What are service accounts?
A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation.
For example, a Compute Engine VM may run as a service account, and that account can be given permissions to access the resources it needs. This way the service account is the identity of the service, and the service account's permissions control which resources the service can access.
A service account is identified by its email address, which is unique to the account.
Differences between a service account and a user account
Service accounts differ from user accounts in a few key ways:
- Service accounts do not have passwords, and cannot log in via browsers or cookies.
- Service accounts are associated with private/public RSA key-pairs that are used for authentication to Google.
- IAM permissions can be granted to allow other users (or other service accounts) to impersonate a service account.
- Service accounts are not members of your G Suite domain, unlike user accounts. For example, if you share assets with all members in your G Suite domain, they will not be shared with service accounts. Similarly, any assets created by a service account cannot be owned or managed by G Suite or Cloud Identity admins. This doesn't apply when using domain-wide delegation, because API calls are authorized as the impersonated user, not the service account itself.
Service account keys
Each service account is associated with two sets of public/private RSA key pairs that are used to authenticate to Google: Google-managed keys, and user-managed keys.
Google-managed key pairs imply that Google stores both the public and private portion of the key, rotates them regularly (each key can be used for signing a maximum of two weeks), and the private key is always held in escrow and is never directly accessible. IAM provides APIs to use these keys to sign on behalf of the service account. See Creating Short-lived service account credentials for more information.
User-managed key pairs imply that you own both the public and private portions of a key pair. You can create one or more user-managed key pairs (also known as "external" keys) that can be used from outside of Google Cloud. Google only stores the public portion of a user-managed key.
Additionally, you can create a public key in the appropriate format and upload it to Google, where it is permanently associated with the specified service account. When you need to perform signing operations on behalf of that service account, such as when creating service account keys, the uploaded public key is used.
The private portion of a user-managed key pair is most commonly used with Application Default Credentials. The private key is then used to authenticate server-to-server applications.
For user-managed keys, you are responsible for security of the private key and
other management operations such as key rotation. User-managed keys can be
managed by the IAM API,
gcloud command-line tool, or the
service accounts page in the Google Cloud Console. You can create up to
10 service account keys per service account to
facilitate key rotation.
Consider using Cloud Key Management Service (Cloud KMS) to help securely manage your keys.
Preventing user-managed keys
User-managed keys are extremely powerful credentials, and they can represent a security risk if they are not managed correctly.
You can limit their use by applying the
constraints/iam.disableServiceAccountKeyCreation Organization Policy Constraint
to projects, folders, or even your entire organization. After applying the
constraint, you can enable user-managed keys in well-controlled locations to
minimize the potential risk caused by unmanaged keys.
Types of service accounts
User-managed service accounts
You can create user-managed service accounts in your project using the
IAM API, the Cloud Console, or the
gcloud command-line tool.
You are responsible for managing and securing these accounts.
By default, you can create up to 100 user-managed service accounts in a project. If this quota does not meet your needs, you can use the Cloud Console to request a quota increase. The default service accounts described on this page do not count towards this quota.
When you create a user-managed service account in your project, you choose a name for the service account. This name appears in the email address that identifies the service account, which uses the following format:
Default service accounts
When you use some Google Cloud services, they create user-managed service accounts that enable the service to deploy jobs that access other Google Cloud resources. These accounts are known as default service accounts.
The default service accounts help you get started with Google Cloud services. For production workloads, we strongly recommend that you create your own user-managed service accounts and grant the appropriate roles to each service account.
When a default service account is created, it is automatically granted the
Editor role (
roles/editor) on your project. This role includes a very large
number of permissions. To follow the principle of least privilege, we strongly
recommend that you disable the automatic role grant by
adding a constraint to your organization policy, or by
revoking the Editor role manually. If you disable or revoke the role grant, you
must decide which roles to grant to the default service accounts.
The following table lists the services that create default service accounts:
|Service||Service account name||Email address|
|App Engine, and any Google Cloud service that uses App Engine||App Engine default service account||
|Compute Engine, and any Google Cloud service that uses Compute Engine||Compute Engine default service account||
Google-managed service accounts
In addition to your user-managed service accounts and default service accounts, you might see other service accounts in your project's IAM policy, in the Cloud Console, and in audit logs. These service accounts are created and managed by Google, and they are used by Google services.
The display name of most Google-managed service accounts ends with "Service Agent" or "Service Account." Some of these service accounts are visible; others are hidden.
Google APIs Service Agent. Your project is likely to contain a service account named the Google APIs Service Agent, with an email address that uses the following format:
This service account runs internal Google processes on your behalf. It is automatically granted the Editor role (
roles/editor) on the project.
Role manager for Google-managed service accounts. Your audit logs for IAM might refer to the service account
This service account manages the roles that are granted to other Google-managed service accounts. It is visible only in audit logs.
For example, if you use a new API, Google might automatically create a new Google-managed service account and grant roles to the service account on your project. Granting these roles generates an audit log entry, which shows that
email@example.com the IAM policy for the project.
Other Google-managed service accounts. Roles might be automatically granted to other Google-managed service accounts on the project. The names of these roles typically end in
The following table lists some of the Google-managed service accounts that
might exist in your project, in addition to the Google APIs Service Agent and
the role manager. It also shows the format of the email address for each of
these service accounts. Replace
project-number with your
project number; you can find the project number on the
Cloud Console dashboard
for your project.
|Google-managed service accounts|
|Artifact Registry Service Account||
|BigQuery Data Transfer Service Agent||
|Cloud AI Platform Notebooks Service Account||
|Cloud Composer Service Agent||
|Cloud Data Fusion Service Account||
|Cloud Dataflow Service Account||
|Cloud Life Sciences Service Agent||
|Cloud Pub/Sub Service Account||
|Cloud Scheduler Service Account||
|Cloud Source Repositories Service Agent||
|Compute Engine Service Agent||
|Google Cloud Dataproc Service Agent||
|Google Cloud Functions Service Agent||
|Google Cloud ML Engine Service Agent||
|Google Cloud Run Service Agent||
|Kubernetes Engine Service Agent||
|TPU Service Agent||
Service account permissions
For instance, Alice can have the editor role on a service account and Bob can have viewer role on a service account. This is just like granting roles for any other Google Cloud resource.
The default Compute Engine and App Engine service accounts are granted editor roles on the project when they are created so that the code executing in your App or VM instance has the necessary permissions. In this case the service accounts are identities that are granted the editor role for a resource (project).
If you want to allow your application to access a Cloud Storage bucket, you grant the service account (that your application uses) the permissions to read the Cloud Storage bucket. In this case the service account is the identity that you are granting permissions for another resource (the Cloud Storage bucket).
The Service Account User role
Granting the Service Account User role to a user for a project gives the user access to all service accounts in the project, including service accounts that may be created in the future.
Granting the Service Account User role to a user for a specific service account gives a user access to only that service account.
Users granted the Service Account User role on a service account can use it to
indirectly access all the resources to which the service account has access. For
example, if a service account has been granted the Compute Admin role
roles/compute.admin), a user that has been granted the Service Account Users
roles/iam.serviceAccountUser) on that service account can act as the
service account to start a Compute Engine instance. In this flow, the
user impersonates the service account to perform any tasks using its granted
roles and permissions.
For more information on granting users roles on service accounts, see Managing service account impersonation.
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 private external 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 policies on those service accounts.
- If your service accounts don't need external keys, delete them.
- If users don't need permission to manage or use service accounts, then remove them from the applicable IAM 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 Understanding service accounts.
The Service Account Token Creator role
This role enables impersonation of service accounts to create OAuth2 access tokens, sign blobs, or sign JWTs.
The Service Account Actor role
This role has been deprecated. If you need to run operations as the service account, use the Service Account User role. To effectively provide the same permissions as Service Account Actor, you should also grant Service Account Token Creator.
Access scopes are the legacy method of specifying permissions for your VM. Before the existence of IAM roles, access scopes were the only mechanism for granting permissions to service accounts. Although they are not the primary way of granting permissions now, you must still set access scopes when configuring an instance to run as a service account. For information on access scopes see Google Compute Engine documentation
Short-Lived Service Account Credentials
You can create short-lived credentials that allow you to assume the identity of a Google Cloud service account. These credentials can be used to authenticate calls to Google Cloud APIs or other non-Google APIs.
The most common use case for these credentials is to temporarily delegate access to Google Cloud resources across different projects, organizations, or accounts. For example, instead of providing an external caller with the permanent credentials of a highly-privileged service account, temporary emergency access can be granted instead. Alternatively, a designated service account with fewer permissions can be impersonated by an external caller without requiring a more highly privileged service account's credentials.
For more information, see Creating Short-Lived Service Account Credentials.
Workload identity federation
You can grant identities from a workload that runs outside of Google Cloud, such as on Amazon Web Services (AWS) or Microsoft Azure, the ability to impersonate a service account. This lets you access resources directly, using short-lived credentials, instead of using a service account key.
To learn more, see Workload identity federation.
Application Default Credentials
Application default credentials are a mechanism to make it easy to use service accounts when operating inside and outside Google Cloud, as well as across multiple Google Cloud projects. The most common use case is testing code on a local machine, and then moving to a development project in Google Cloud, and then moving to a production project in Google Cloud. Using Application Default Credentials ensures that the service account works seamlessly; when testing on your local machine, it uses a locally-stored service account key, but when running on Compute Engine, it uses the project's default Compute Engine service account. See Application Default Credentials for more information.
For best practices on using service accounts, see Understanding Service Accounts.
Read the following guides to understand how to: