Background
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
Service accounts can be thought of as both a resource and as an identity.
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 principals, 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.
- Activity analyzer lets you check when a service account or key was last used.
You can also use service account usage metrics to track service account and key usage generally.
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 principals.
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 principals.
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 principals, 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 principals, 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:
- 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.
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
instances.setServiceAccountmethod.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.
What's next
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