This page explains what service accounts are and describes importantconsiderations for managing your service accounts at each stage of theirlifecycle.
What are service accounts?
A service account is a special kind of account typically used by an applicationor 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 theaccount.
Applications use service accounts to makeauthorized API callsby authenticating as either the service account itself, or as Google Workspaceor Cloud Identity users throughdomain-wide delegation.When an application authenticates as a service account, it has access to allresources that the service account has permission to access.
The most common way to let an application authenticate as a service accountis to attach a service account to the resourcerunning the application. For example, you can attach a service account to aCompute Engine instance so that applications running on that instance canauthenticate as the service account. Then, you can grant the service accountIAM roles to let the service account—and, by extension,applications on the instance—access Google Cloud resources.
There are other ways to let applications to authenticate as service accountsbesides attaching a service account. For example, you could set up workloadidentity federation to allow external workloadsto authenticate as service accounts, or create a service account keyand use it in any environment to obtain OAuth 2.0 access tokens.
To learn more about service account authentication for applications, seeOverview of identities for workloads.
Principals, such as users and other service accounts, can also authenticate asservice accounts. For more information, see Service accountimpersonation 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 andmanage. These service accounts are often used as identities forworkloads.
Default service accounts: User-managed service accounts that are createdautomatically when you enable certain Google Cloud services. You areresponsible for managing these service accounts.
Google-managed service accounts: Google-created and Google-managed serviceaccounts that allow services to access resources on your behalf.
To learn more about the different types of service accounts, see Types ofservice accounts.
Service account credentials
Applications and principals authenticate as a service account by doing one ofthe following:
- Obtaining short-lived credentials. In many cases, such as attachedservice accounts and commands using the gcloud CLI
--impersonate-service-accountflag, these credentials are obtainedautomatically—you don't need to create or manage them yourself. - Using a service account key to sign a JSON Web Token (JWT) and exchanging itfor an access token. Because service account keys are a security risk if notmanaged correctly, you should choose a more secure alternative to service account keyswhenever possible.
To learn more about service account authentication, see Service accountcredentials.
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 accountimpersonation.
Service accounts and Google Workspace domains
Service accounts do not belong to your Google Workspace domain, unlikeuser accounts. If you share Google Workspace assets, like docs orevents, with your entire Google Workspace domain, they are not sharedwith service accounts. Similarly, Google Workspace assets created by aservice account are not created in your Google Workspace domain. As aresult, your Google Workspace and Cloud Identity admins can't own ormanage these assets.
Service account permissions
Service accounts are principals. This means that you can grantservice accounts access to Google Cloud resources. For example, you couldgrant a service account the Compute Admin role (roles/compute.admin) on aproject. Then, the service account would be able to manage Compute Engineresources in that project.
However, service accounts are also resources. This means that youcan 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 attachthat service account to resources. Or, you could grant a user the ServiceAccount Admin role (roles/iam.serviceAccountAdmin) to let the user do thingslike view, edit, disable, and delete the service account.
The following sections discuss how to manage service accounts as principals andas resources.
Service accounts as principals
Because service accounts are principals, you can let a service account accessresources in your project by granting it a role, just like you would for anyother principal. For example, if you want to let your application's serviceaccount access objects in a Cloud Storage bucket, you can grant the serviceaccount the Storage Object Viewer role (roles/storage.objectViewer) on thebucket.
As with all types of principals, you should only give the service account theminimum set of permissions required to achieve its goal.
As with other principals, you can add service accounts to a Google group, thengrant roles to the group. However, adding service accounts to groups is not abest practice. Service accounts are used by applications, andeach application is likely to have its own access requirements.
To learn how to grant roles to principals, including service accounts, seeManage access to projects, folders, and organizations.
Service accounts as resources
Service accounts are also resources that can have their own allow policies. As aresult, you can let other principals access a service account by granting them arole on the service account, or on one of the service account's parentresources. For example, to let a user impersonate a serviceaccount, 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, keepin mind that the user can access all the resources that the service account canaccess. Use caution when letting users impersonate highly privileged serviceaccounts, such as the Compute Engine andApp Engine default service accounts.
For more information on the roles that you can grant to principals on serviceaccounts, see Service account permissions.
To learn how to grant a principal a role on a service account, see Manage accessto service accounts.
Service account lifecycle
As you manage your projects, you'll likely create, manage, and delete manydifferent service accounts. This section describes key considerationsfor 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 serviceaccount, 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 arespread across many projects.
Centralize service accounts in separate projects.
This approach puts all of the service accounts for your organization in asmall number of projects, which can make the service accounts easier tomanage. However, it requires extra setup if youattach service accounts to resources in other projects, whichallows those resources to use the service account as their identity.
When a service account is in one project, and it accesses a resource inanother project, you usually must enable the API for thatresource in both projects. For example, if you have a service account in theproject
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 accountsin a project. If you need to create additional service accounts,request a quota increase.
To learn how to create a service account, see Create serviceaccounts.
Prevent the creation of service accounts
To better control where service accounts are created, you might want to preventservice account creation in some projects in your organization.
You can prevent the creation of service accounts by enforcing theconstraints/iam.disableServiceAccountCreationorganization 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 anorganization, then some Google Cloud services cannot createdefault service accounts. As a result, if the project runsworkloads that need toauthenticate as a service account, the projectmight not contain a service account that the workload can use.
To address this issue, you can enable service account impersonation acrossprojects. When you enable this feature, you cancreate service accounts in a centralized project, then attach the serviceaccounts to resources in other projects. Workloads running on those resourcescan use the attached service accounts to authenticate, making the defaultservice accounts unnecessary.
Some features, such as workload identityfederation, require you to create serviceaccounts.
If you do not use workload identity federation, consider using organizationpolicy constraints toblock federation from all identity providers.
Keep track of service accounts
Over time, as you create more and more service accounts, you might lose track ofwhich service account is used for what purpose.
The display name of a service account is a good way to capture additionalinformation about the service account, such as the purpose of the serviceaccount or a contact person for the account. For new service accounts, you canpopulate the display name when creating the service account. For existingservice accounts use the serviceAccounts.update() method tomodify the display name.
Use service accounts with Compute Engine
Compute Engine instances need to run as service accounts to have accessto other Google Cloud resources. To help secure yourCompute Engine instances, consider the following:
You can create instances in the same project with different serviceaccounts. To change the service account of an instance after it's created, usethe instances.setServiceAccount method.
To set up authorization for attached service accounts, you need toconfigure access scopes in addition to configuringIAM roles.
Since instances depend on their service accounts to have access toGoogle Cloud resources, avoid deleting service accounts when they arestill used by running instances.
To learn more about using service accounts with Compute Engine, seeService accounts in the Compute Enginedocumentation.
Identify unused service accounts
After some time, you might have service accounts in your projects that you nolonger use.
Unused service accounts create an unnecessary security risk, so we recommenddisabling unused service accounts, thendeleting the service accounts when you are sure that you no longerneed them. You can use the following methods to identify unused serviceaccounts:
- Service account insights tell you which service accounts inyour project have not authenticated in the past 90 days.
- Activity Analyzer lets you check when a serviceaccount or key was last used.
You can also use service account usage metrics to track serviceaccount and key usage generally.
If you are an Security Command Center Premium customer, you can useEvent Threat Detection to get a notification when a dormant service accounttriggers an action. Dormant service accounts are service accounts that have beeninactive for more than 180 days. After a service account isused, it is no longer dormant.
Delete service accounts
Before deleting a service account, disable the service account tomake sure it isn't necessary. Disabled service accounts can be re-enabled ifthey are still in use.
After you confirm that a service account isn't necessary, you can deletethe service account.
Recreate deleted service accounts
It is possible to delete a service account and then create a new serviceaccount with the same name.
When you delete a service account, its role bindings are not immediatelydeleted. Instead, the role bindings list the service account with the prefixdeleted:. For an example, seePolicies with deleted principals.
If you create a new service account with the same name as a recently deletedservice account, the old bindings may still exist; however, they will notapply to the new service account even though both accounts have the same emailaddress. This behavior occurs because service accounts are given a unique IDwithin Identity and Access Management (IAM) at creation. Internally, all role bindings aregranted using these IDs, not the service account's email address. Therefore, anyrole bindings that existed for a deleted service account do not apply to a newservice account that uses the same email address.
Similarly, if youattach a service account to a resource, thendelete 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 everyservice account. Also, if you accidentally delete a service account, you can tryto undelete the service account instead of creating a new serviceaccount.
If you cannot undelete the original service account, and you need to create anew service account with the same name and the same roles, you must grant theroles to the new service account. For details, seePolicies with deleted principals.
If you also need the new service account to be attached to the same resourcesas the original service account, do one of the following:
- For Compute Engine instances, you canchange the service account that is attached to the instanceto replace the original service account with the new service account.
- For all other resources, you must delete the existing resource, then create anew resource of the same type andattach the new service account.
What's next
- Find out how to create service accounts.
- Get best practices for working with service accounts.
- Review best practices for managing service account keys.
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
