This page explains what service accounts are and describes important considerations for managing your service accounts at each stage of their lifecycle.
What are service accounts?
A service account is a special kind of account typically used by an application or compute workload, such as a Compute Engine instance, rather than a person. A service account is identified by its email address, which is unique to the account.
Applications use service accounts to make authorized API calls by authenticating as either the service account itself, or as Google Workspace or Cloud Identity users through domain-wide delegation. When an application authenticates as a service account, it has access to all resources that the service account has permission to access.
The most common way to let an application authenticate as a service account is to attach a service account to the resource running the application. For example, you can attach a service account to a Compute Engine instance so that applications running on that instance can authenticate as the service account. Then, you can grant the service account IAM roles to let the service account—and, by extension, applications on the instance—access Google Cloud resources.
There are other ways to let applications authenticate as service accounts besides attaching a service account. For example, you could set up Workload Identity Federation to allow external workloads to authenticate as service accounts, or create a service account key and use it in any environment to obtain OAuth 2.0 access tokens.
To learn more about service account authentication for applications, see Overview of identities for workloads.
Principals, such as users and other service accounts, can also authenticate as service accounts. For more information, see Service account impersonation on this page.
Types of service accounts
In Google Cloud, there are several different types of service accounts:
User-managed service accounts: Service accounts that you create and manage. These service accounts are often used as identities for workloads.
Default service accounts: User-managed service accounts that are created automatically when you enable certain Google Cloud services. You are responsible for managing these service accounts.
Service agents: Service accounts that are created and managed by Google Cloud, and that allow services to access resources on your behalf.
To learn more about the different types of service accounts, see Types of service accounts.
Service account credentials
Applications and principals authenticate as a service account by doing one of the following:
- Obtaining short-lived credentials. In many cases, such as attached
service accounts and commands using the gcloud CLI
--impersonate-service-accountflag, these credentials are obtained automatically—you don't need to create or manage them yourself. - Using a service account key to sign a JSON Web Token (JWT) and exchanging it for an access token. Because service account keys are a security risk if not managed correctly, you should choose a more secure alternative to service account keys whenever possible.
To learn more about service account authentication, see Service account credentials.
Service account impersonation
When an authenticated principal, such as a user or another service account, authenticates as a service account to gain the service account's permissions, it's called impersonating the service account. Impersonating a service account lets an authenticated principal access whatever the service account can access. Only authenticated principals with the appropriate permissions can impersonate service accounts.
Impersonation is useful when you want to change a user's permissions without changing your Identity and Access Management (IAM) policies. For example, you can use impersonation to temporarily grant a user elevated access, or to test whether a specific set of permissions is sufficient for a task. You can also use impersonation to locally develop applications that can only run as a service account, or to authenticate applications that run outside of Google Cloud.
To learn more about service account impersonation, see Service account impersonation.
Service accounts and Google Workspace domains
Service accounts do not belong to your Google Workspace domain, unlike user accounts. If you share Google Workspace assets, like documents or events, with your entire Google Workspace domain, they are not shared with service accounts.
Service accounts can't own Google Workspace assets. They can, however, create assets in a shared drive in the domain. Assets created in a shared drive are owned and managed by your organization.
Service account permissions
Service accounts are principals. This means that you can grant
service accounts access to Google Cloud resources. For example, you could
grant a service account the Compute Admin role (roles/compute.admin) on a
project. Then, the service account would be able to manage Compute Engine
resources in that project.
However, service accounts are also resources. This means that you
can give other principals permission to access the service account. For example,
you could grant a user the Service Account User role
(roles/iam.serviceAccountUser) on a service account to let the user attach
that service account to resources. Or, you could grant a user the Service
Account Admin role (roles/iam.serviceAccountAdmin) to let the user do things
like view, edit, disable, and delete the service account.
The following sections discuss how to manage service accounts as principals and as resources.
Service accounts as principals
Because service accounts are principals, you can manage access for service
accounts 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 bucket. Or, if you want to ensure that an
application's service account can't change a project's IAM
policies, you could use a deny policy to prevent the service account from using
the resourcemanager.projects.setIamPolicy permission on that project. To learn
more about managing access for principals, see Access in
Google Cloud.
You can manage access for individual service accounts or for all service accounts in a specific project, folder, or organization. When managing access for service accounts, use the following principal identifiers to refer to the service accounts:
| Principal type | Principal identifier |
|---|---|
| An individual service account |
Example: |
| All service accounts in a project |
Example: |
| All service accounts in all projects in a folder |
Example: |
| All service accounts in all projects in an organization |
Example: |
As with all types of principals, you should only give the service account the minimum set of permissions required to achieve its goal.
If service accounts in a specific project, folder, or organization share requirements, then use service account principal sets to grant them roles instead of using custom groups.
To learn how to grant roles to principals, including service accounts, see Manage access to projects, folders, and organizations.
Service accounts as resources
Service accounts are also resources that can have their own allow 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 Token Creator role
(roles/iam.serviceAccountTokenCreator) on the service account.
When granting a role that allows a user to impersonate a service account, keep in mind that the user can access all the resources that the service account can access. Use caution when letting users impersonate highly privileged service accounts, such as the Compute Engine and App Engine default service accounts.
For more information on the roles that you can grant to principals on service accounts, see Service account permissions.
To learn how to grant a principal a role on a service account, see Manage access to service accounts.
Service account lifecycle
As you manage your projects, you'll likely create, manage, and delete many different service accounts. This section describes key considerations for managing your service accounts at the various stages of their lifecycle.
Where to create service accounts
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 easier 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 projectmy-application, you must enable the Cloud SQL API in bothmy-service-accountsandmy-application.By default, you can create up to 100 service accounts in a project. If you need to create additional service accounts, request a quota adjustment.
To learn how to create a service account, see Create service accounts.
Prevent the creation of service accounts
To better control where service accounts are created, you might want to prevent service account creation in some projects in your organization.
You can prevent the creation of service accounts by enforcing the
constraints/iam.disableServiceAccountCreation
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 authenticate as 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. Workloads running on those resources can use the attached service accounts to authenticate, making the default service accounts unnecessary.
Some features, such as Workload Identity Federation, require you to create service accounts.
If you don't use Workload Identity Federation, consider using organization policy constraints to block federation from all identity providers.
Keep 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