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 Google Workspace or Cloud Identity users through domain-wide delegation.
For example, a Compute Engine VM can 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.
- You can let other users or service accounts impersonate a service account.
Service accounts do not belong to your Google Workspace domain, unlike user accounts. If you share Google Workspace assets, like docs or events, with your entire Google Workspace domain, they are not shared with service accounts. Similarly, Google Workspace assets created by a service account are not created in your Google Workspace domain. As a result, your Google Workspace and Cloud Identity admins can't own or manage these assets.
Preventing creation of service accounts
You can prevent the creation of service accounts by enforcing the
organization policy constraint in an organization,
project, or folder.
Before you enforce this constraint, consider the following limitations:
If you enforce this constraint in a project, or in all projects within an organization, then some Google Cloud services cannot create default service accounts. As a result, if the project runs workloads that need to impersonate a service account, the project might not contain a service account that the workload can use.
To address this issue, you can enable service account impersonation across projects. When you enable this feature, you can create service accounts in a centralized project, then attach the service accounts to resources in other projects.
Some features, such as workload identity federation, require you to create service accounts.
If you do not use workload identity federation, consider using organization policy constraints to block federation from all identity providers.
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 Secret Manager to help securely manage your keys.
Preventing creation of user-managed keys
User-managed keys are extremely powerful credentials, and they can represent a security risk if they are not managed correctly.
To limit the use of user-managed keys, you can enforce the following organization policy constraints in an organization, project, or folder:
constraints/iam.disableServiceAccountKeyCreation: Prevents principals from creating user-managed service account keys.
constraints/iam.disableServiceAccountKeyUpload: Prevents principals from uploading a public key for a service account.
If you enforce these constraints because you are using workload identity federation, consider using the organization policy constraints for workload identity federation to specify which identity providers are allowed.
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 enable or 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.
If your application runs in a Google Cloud environment that has a default service account, your application can use the credentials for the default service account to call Google Cloud APIs. Alternatively, you can create your own user-managed service account and use it to authenticate. For details, see Finding credentials automatically.
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
Some Google Cloud services need access to your resources so that they can act on your behalf. For example, when you use Cloud Run to run a container, the service needs access to any Pub/Sub topics that can trigger the container.
To meet this need, Google creates and manages service accounts for many Google Cloud services. These service accounts are known as Google-managed service accounts. You might see Google-managed service accounts in your project's IAM policy, in audit logs, or on the IAM page in the Cloud Console.
Google-managed service accounts are not listed in the Service accounts page in the Cloud Console.
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
firstname.lastname@example.org the IAM policy for the project.
Other Google-managed service accounts. Your project might contain other Google-managed service accounts that act on behalf of individual services. These service accounts are sometimes called service agents. Roles might be automatically granted to these service agents; the names of these roles typically end in
For a complete list of service agents and the roles that are automatically granted to each one, see Service agents.
Service account locations
Each service account is located in a project. After you create a service account, you cannot move it to a different project.
There are a few ways to organize your service accounts into projects:
Create service accounts and resources in the same project.
This approach makes it easy to get started with service accounts. However, it can be difficult to keep track of your service accounts when they are spread across many projects.
Centralize service accounts in separate projects.
This approach puts all of the service accounts for your organization in a small number of projects, which can make the service accounts easier to manage. However, it requires extra setup if you attach service accounts to resources in other projects, which allows those resources to use the service account as their identity.
When a service account is in one project, and it accesses a resource in another project, you usually must enable the API for that resource in both projects. For example, if you have a service account in the project
my-service-accountsand a Cloud SQL instance in the project
my-application, you must enable the Cloud SQL API in both
By default, you can create up to 100 service accounts in a project. If you need to create additional service accounts, request a quota increase.
Service account permissions
Because service accounts are identities, you can let a service account access
resources in your project by granting it a role, just like you would for any
other principal. For example, if you want to let your application's service
account access objects in a Cloud Storage bucket, you can grant the service
account the Storage Object Viewer role (
roles/storage.objectViewer) on the
However, service accounts are also resources that accept IAM
policies. As a result, you can let other principals access a service account by
granting them a role on the service account, or on one of the service account's
parent resources. For example, to let a user impersonate a service account, you
could grant the user the Service Account User role
roles/iam.serviceAccountUser) on the service account.
For more information on granting roles to principals, including service accounts, see Granting, changing, and revoking access.
For more information on granting roles on service accounts, see Managing service account impersonation.
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 might 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.
Access scopes are a legacy method of specifying permissions for a
Compute Engine virtual machine (VM) instance. They define the default
OAuth scopes used in requests from the
gcloud tool and client
Google Cloud now uses IAM, not access scopes, to specify permissions for Compute Engine instances. However, you are still required to set an access scope when you configure an instance to impersonate a service account.
For more information, see the 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 is a tool that Google Cloud Client Libraries use to automatically discover service account credentials. You can specify a service account key in an environment variable, and Application Default Credentials automatically uses that service account key. If you do not specify a key, then Application Default Credentials uses the service account that is attached to the resource that is running your code, or the default service account for the service that is running your code.
To learn more, see Finding credentials automatically.
For best practices on using service accounts, see Understanding Service Accounts.
Read the following guides to understand how to:
- Create and manage service accounts.
- Create and manage service account keys.
- Grant IAM roles to all types of principals, including service accounts.
- Use role recommendations to downscope permissions for all principals, including 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