A service account is a special type of Google account intended to represent a non-human user that needs to authenticate and be authorized to access data in Google APIs.
Typically, service accounts are used in scenarios such as:
- Running workloads on virtual machines (VMs).
- Running workloads on on-premises workstations or data centers that call Google APIs.
- Running workloads which are not tied to the lifecycle of a human user.
Your application assumes the identity of the service account to call Google APIs, so that the users aren't directly involved.
Managing service accounts
When thinking of the service account as an identity, you can grant a role to a service account, allowing it to access a resource (such as a project).
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
Granting access to service accounts
Granting access to a service account to access a resource is similar to granting access to any other identity. For example, if you have an application running on Compute Engine and you want the application to only have access to create objects in Cloud Storage. You can create a service account for the application and grant it the Storage Object Creator role.
Learn about Granting roles to all types of members, including service accounts.
Keeping track of service accounts
Over time, as you create more and more service accounts, you might lose track of which service account is used for what purpose.
The display name of a service account is a good way to capture additional
information about the service account, such as the purpose of the service
account or a contact person for the account. For new service accounts, you can
populate the display name when creating the service account. For existing
service accounts use the
serviceAccounts.update() method to
modify the display name.
Identifying unused service accounts
Unused service accounts create an unnecessary security risk, so we recommend disabling unused service accounts, then deleting the service accounts when you are sure that you no longer need them. You can use the following methods to identify unused service accounts:
- Service account insights tell you which service accounts in your project have not authenticated in the past 90 days.
- Service account usage metrics allow you to check when a service account was last used.
Deleting and recreating service accounts
It is possible to delete a service account and then create a new service account with the same name.
When you delete a service account, its role bindings are not immediately
deleted. Instead, the role bindings list the service account with the prefix
deleted:. For an example, see Policies with deleted members.
If you create a new service account with the same name as a recently deleted service account, the old bindings may still exist; however, they will not apply to the new service account even though both accounts have the same email address. This behavior occurs because service accounts are given a unique ID within Identity and Access Management (IAM) at creation. Internally, all role bindings are granted using these IDs, not the service account's email address. Therefore, any role bindings that existed for a deleted service account do not apply to a new service account that uses the same email address.
Similarly, if you attach a service account to a resource, then delete the service account and create a new service account with the same name, the new service account will not be attached to the resource.
To prevent this unexpected behavior, consider using a new, unique name for every service account. Also, if you accidentally delete a service account, you can try to undelete the service account instead of creating a new service account.
If you cannot undelete the original service account, and you need to create a new service account with the same name and the same roles, you must grant the roles to the new service account. For details, see Policies with deleted members.
If you also need the new service account to be attached to the same resources as the original service account, do one of the following:
- For Compute Engine instances, you can change the service account that is attached to the instance to replace the original service account with the new service account.
- For all other resources, you must delete the existing resource, then create a new resource of the same type and attach the new service account.
Permissions for service accounts
This section describes common scenarios for permissions granted to service accounts, or user accounts that have the permissions to impersonate service accounts:
Granting minimum permissions to service accounts
As with all types of members, you should only grant the service account the minimum set of permissions required to achieve its goal. Learn about granting roles to all types of members, including service accounts.
When granting permissions to users to access a service account, keep in mind that the user can access all the resources for which the service account has permissions. Therefore it's important to configure permissions of your service accounts carefully; that is, be strict about who on your team can act as (or impersonate) a service account. Use particular caution when allowing users to impersonate highly privileged service accounts, such as the Compute Engine and App Engine default service accounts.
Users with IAM roles to update the App Engine and Compute Engine instances (such as App Engine Deployer or Compute Instance Admin) can effectively run code as the service accounts used to run these instances, and indirectly gain access to all the resources for which the service accounts has access. Similarly, SSH access to a Compute Engine instance may also provide the ability to execute code as that instance.
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
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
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
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
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
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
method. The Google-managed private key is always held in escrow and is never
signBlob() allows signing of arbitrary payloads (such as
Cloud Storage-signed URLs), while
signJwt() only allows signing
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
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
iam.serviceAccounts.getAccessToken permission on C.
Generating OpenID Connect (OIDC) ID tokens
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
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
roles/iam.serviceAccountAdmin(Service Account 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.
Managing service account keys
There are two types of service account keys:
Google Cloud-managed keys. These keys are used by Google Cloud services such as App Engine and Compute Engine. They cannot be downloaded, and are automatically rotated and used for signing for a maximum of two weeks. The rotation process is probabilistic; usage of the new key will gradually ramp up and down over the key's lifetime. We recommend caching the public key set for a service account for at most 24 hours to ensure that you always have access to the current key set.
User-managed keys. These keys are created, downloadable, and managed by users. After you delete them from the service account, you cannot use them to authenticate.
For user-managed keys, you need to make sure that you have processes in place to address key management requirements such as:
- Key storage
- Key distribution
- Key revocation
- Key rotation
- Protecting the keys from unauthorized users
- Key recovery
Anyone who has access to a valid private key for a service account will be able to access resources through the service account. Note that the lifecycle of the key's access to the service account (and thus, the data the service account has access to) is independent of the lifecycle of the user who has downloaded the key.
Always discourage developers from checking keys into the source code or leaving them in the Downloads directory of their workstation.
To enhance the security of keys, follow the guidance below:
Use the IAM service account API to automatically rotate your service account keys. You can rotate a key by creating a new key, switching applications to use the new key and then deleting the old key. Use the
serviceAccount.keys.delete()methods together to automate the rotation. The Google Cloud-managed keys are rotated approximately once a week.
- Use the
serviceAccount.keys.list()method to audit service accounts and keys.
- Use the
Using service accounts with Compute Engine
Compute Engine instances need to run as service accounts to have access to other Google Cloud resources. To make sure that your Compute Engine instances are more secure, consider the following:
You can create VMs in the same project with different service accounts. To change the service account of a VM after it's created, use the
You can grant IAM roles to service accounts to define what they can access. In many cases you won't need to rely on scopes anymore. This gives you the advantage of being able to modify permissions of a VM's service account without recreating the instance.
Since instances depend on their service accounts to have access to Google Cloud resources, avoid deleting service accounts when they are still used by running instances. If you delete the service accounts, the instances may start failing their operations.
- Read our best practices for using and managing service accounts
- Learn more about best practices for securing 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