Best practices for using service accounts  |  IAM Documentation  |  Google Cloud (2024)

Service accounts represent non-human users. They're intended for scenarios wherea workload, such as a custom application, needs to access resources or performactions without end-user involvement.

Service accounts differ from normal user accounts in multiple ways:

• They don't have a password and can't be used for browser-based sign-in.
• They're created and managed as a resource that belongs to a Google Cloud project.In contrast, users are managed in a Cloud Identity orGoogle Workspace account.
• They're specific to Google Cloud.In contrast, the users managed in Cloud Identity or Google Workspacework across a multitude of Google products and services.
• They're both a resource and a principal:
  • As a principal, a service account can be granted access to resources,like a Cloud Storage bucket.
  • As a resource, a service account can be accessed and possiblyimpersonated by otherprincipals, like a user or group.

Although service accounts are a useful tool, there are several ways in which aservice account can be abused:

• Privilege escalation: A bad actor might gain access to resources theyotherwise wouldn't have access to by impersonating the service account.
• Spoofing: A bad actor might use service account impersonation to obscuretheir identity.
• Non-repudiation: A bad actor might conceal their identity and actions byusing a service account to carry out operations on their behalf. In somecases, it might not be possible to trace these actions to the bad actor.
• Information disclosure: A bad actor might derive information about yourinfrastructure, applications, or processes from the existence of certainservice accounts.

To help secure service accounts, consider their dual nature:

• Because a service account is a principal, you must limit its privileges toreduce the potential harm that can be done by a compromised service account.
• Because a service account is a resource, you must protect it from beingcompromised.

This guide presents best practices for managing, using, and securing service accounts.

Choose when to use service accounts

Not every scenario requires a service account to access Google Cloudservices, and many scenarios can authenticate with a more secure method thanusing a service account key. We recommend that you avoid using service accountkeys whenever possible.

When you access Google Cloud services by using the Google Cloud CLI, Cloud Client Libraries, tools that support Application Default Credentials (ADC) like Terraform, or REST requests, use the following diagram to help you choose an authentication method:

This diagram guides you through the following questions:

1. Are you running code in a single-user development environment, such as your own workstation, Cloud Shell, or a virtual desktop interface?
   1. If yes, proceed to question 4.
   2. If no, proceed to question 2.
2. Are you running code in Google Cloud?
   1. If yes, proceed to question 3.
   2. If no, proceed to question 5.
3. Are you running containers in Google Kubernetes Engine or GKE Enterprise?
   1. If yes, use workload identity federation for GKE to attach service accounts to Kubernetes pods.
   2. If no, attach a service account to the resource.

4. Does your use case require a service account?

   For example, you want to configure authentication and authorization consistently for your application across all environments.

   1. If no, authenticate with user credentials.
   2. If yes, impersonate a service account with user credentials.
5. Does your workload authenticate with an external identity provider that supports workload identity federation?
   1. If yes, configure workload identity federation to let applications running on-premises or on other cloud providers use a service account.
   2. If no, create a service account key.

Manage service accounts

Service accounts differ from normal user accounts, not only in how they're used,but also in how they must be managed. The following sections provide bestpractices for managing service accounts.

Manage service accounts as resources

Regular user accounts are typically managed according to an organization'sjoiner-mover-leaver processes: When an employee joins, a new user account iscreated for them. When they move departments, their user account is updated. Andwhen they leave the company, their user account is suspended or deleted.

In contrast, service accounts aren't associated with any particular employee.Instead, it's best to think of service accounts as resources that belong to—or arepart of—another resource, such as a particular VM instance or an application.

To effectively manage service accounts, don't look at service accounts in isolation.Instead, consider them in the context of the resource they're associated with andmanage the service account and its associated resource as one unit: Apply the sameprocesses, same lifecycle, and same diligence to the service account and itsassociated resource, and use the same tools to manage them.

Create single-purpose service accounts

Sharing a single service account across multiple applications can complicate themanagement of the service account:

• The applications might have different life cycles. If an application is decommissioned,it might not be clear whether the service account can be decommissioned as wellor whether it's still needed.
• Over time, the access requirements of applications might diverge. If applicationsuse the same service account, then you might need to grant the serviceaccount access to an increasing number of resources, which in turn increasesthe overall risk.
• Cloud Audit Logs include the name of the service account that performed a changeor accessed data, but they don't show the name of the application that usedthe service account. If multiple applications share a service account, youmight not be able to trace activity back to the correct application.

In particular, some Google Cloud services, including App Engineand Compute Engine, create adefault service account that has theEditor role (roles/editor) on the project by default. When you create aresource such as a Compute Engine virtual machine (VM) instance, and youdon't specify a service account, the resource can automatically use the defaultservice account. Although the default service account makes it easier for you toget started, it's very risky to share such a powerful service account acrossmultiple applications.

You can take several steps to avoid these complications:

• Create dedicated service accounts for each application, and avoid usingdefault service accounts.
• Don't use automatic role grants for default service accounts.
• Use Google'stools to understand service account usage,which can help you monitor usage and prevent service accounts from beingshared across multiple applications.

Follow a naming and documentation convention

To help track the association between a service and an application or resource,follow a naming convention when creating new service accounts:

• Add a prefix to the service account email address that identifies how theaccount is used. For example:
  • vm- for service accounts attached to a VM instance.
  • wi- for service accounts used by Workload Identity.
  • wif- for service accounts used by workload identity federation.
  • onprem- for service accounts used by on-premises applications.
• Embed the name of the application in the service account email address,for example: vm-travelexpenses@ if the VM runs a travel expenses application.
• Use the description field to add a contact person, links to relevant documentation,or other notes.

Don't embed sensitive information or terms in the email address of a service account.

Identify and disable unused service accounts

When a service account isn't used anymore, disable the service account.By disabling unused service accounts, you reduce the risk of the service accountsbeing abused for lateral movement or for privilege escalation by a bad actor.

For single-purpose service accounts that are associatedwith a particular resource, such as a VM instance, disable the service account assoon as the associated resource is disabled or deleted.

For service accounts that are used for multiple purposes or shared acrossmultiple resources, it can be more difficult to identify whether the serviceaccount is still used. In these cases, you can useActivity Analyzerto view the most recent authentication activities for your service accounts.

Disable unused service accounts before deleting them

If you delete a service account and then create a new service account with thesame name, the new service account is assigned a different identity. As a result,none of the original IAM bindings apply to the new service account.In contrast, if you disable and re-enable a service account, all IAMbindings stay intact.

To avoid inadvertently losing IAM bindings, it's best to not deleteservice accounts immediately. Instead, disable a service account if it isn'tneeded anymore and only delete it after a certain period has elapsed.

Never delete default service accounts such as theApp Engine orCompute Engine default service account.These service accounts can't be recreated without disabling and reenabling therespective API, which might break your existing deployment. If you don't use thedefault service accounts, disable them instead.

Limit service account privileges

Service accounts are principals and can be granted access to a resource like aregular user account. However, service accounts often have greater access tomore resources than a typical user. In addition, as you add functionality toyour applications, their service accounts tend to gain more and more access overtime; you might also forget to revoke access that's no longer needed.

Don't use automatic role grants for default service accounts

Some Google Cloud services create default service accountswhen you first enable their API in a Google Cloud project. By default, these service accountsare granted the Editor role (roles/editor) on your Google Cloud project, which allowsthem to read and modify all resources in the Google Cloud project. The role is granted foryour convenience, but isn't essential for the services to work: To access resourcesin your Google Cloud project, Google Cloud services useservice agents, not the default service accounts.

To prevent default service accounts from automatically being granted the Editorrole, enable the Disable Automatic IAM Grants for Default Service Accounts(constraints/iam.automaticIamGrantsForDefaultServiceAccounts) constraint to your organization.To apply the constraint to multiple Google Cloud projects,configure it on the folder or the organization node. Applying theconstraint doesn't remove the Editor role from existing default service accounts.

If you apply this constraint, then default service accounts in new projects will not have any access to your Google Cloud resources. You must grant appropriate roles to the default service accounts so that they can access your resources.

Don't rely on access scopes when attaching a service account to a VM instance

When you attach a service account to a VM instance, you canspecify one or more access scopes.Access scopes let you restrict which services the VM can access. Therestrictions are applied in addition to allow policies.

Access scopes are coarse-grained. For example, by using thehttps://www.googleapis.com/auth/devstorage.read_only scope,you can restrict access to Cloud Storage read-only operations, but youcan't restrict access to specific buckets. Therefore, access scopes aren't asuitable replacement for fine-grained allow policies.

Instead of relying on access scopes, create adedicated service accountand use fine-grained allow policies to restrict which resources the serviceaccount has access to.

Avoid using groups for granting service accounts access to resources

In an organization, it's common that multiple employees perform similar or overlappingjob functions and therefore require similar access to resources. By using groups,you can take advantage of these similarities to reduce administrative overhead.

Service accounts are intended to be used by applications. It's rare thatmultiple applications perform the same function and therefore have similar oridentical access requirements. Instead, applications tend to be unique and theresources they require access to are typically different for each application.

Using groups to grant service accounts access to resources can lead to a few bad outcomes:

• A proliferation of groups, with each group containing only one or a fewservice accounts.
• Permission creep: Over time, a group is granted access to an increasing numberof resources although each member of the group only requires access to asubset of the resources.

Unless the purpose of a group is narrowly defined, it's best to avoid usinggroups. Instead, directly grantservice accounts access to the resources they need.

Avoid using domain-wide delegation

Domain-wide delegationenables a service account to impersonate any user in a Cloud Identity orGoogle Workspace account. Domain-wide delegation enables a service accountto perform certain administrative tasks in Google Workspace andCloud Identity, or to access Google APIs that don't support serviceaccounts from outside of Google Cloud.

Domain-wide delegation doesn't restrict a service account to impersonate aparticular user, but allows it to impersonate any user in a Cloud Identityor Google Workspace account, including super-admins. Allowing a serviceaccount to use domain-wide delegation can therefore make the service account anattractive target for privilege escalation attacks.

Avoid using domain-wide delegation if you can accomplish your task directlywith a service account or by using theOAuth consent flow.

If you can't avoid using domain-wide delegation, restrict the set of OAuth scopesthat the service account can use. Although OAuth scopesdon't restrict which users the service account can impersonate, they restrictthe types of user data that the service account can access.

Don't use service accounts to access user data without the user's consent

An application might require access to sensitive or personal user data. Examplesof such data include a user's mailbox or calendar, documents stored onGoogle Drive, or a BigQuery dataset that contains sensitive data.

Using a service account to access user data can be appropriate if the applicationperforms unattended background tasks, such as indexing or data loss prevention(DLP) scans, or if the end user hasn't authenticated with a Google identity.In all other scenarios where an application acts on an end user's behalf, it'sbest to avoid using service accounts.

Instead of using a service account to access user data (possibly performing aprincipal transition), use theOAuth consent flowto request the end user's consent. Then let the application act under the enduser's identity. By using OAuth instead of a service account, you help ensurethat:

• Users can review which resources they're about to grant the applicationaccess to, and can explicitly express or deny their consent.
• Users can revoke their consent on their My Accountpage at any time.
• You don't need a service account that has unfettered access to all user's data.

By letting the application use end-user credentials, you defer permission checksto Google Cloud APIs. This approach limits the risk of accidentally exposingdata that the user shouldn't be allowed to access because of a coding error(confused deputy problem).

Use the IAM Credentials API for temporary privilege elevation

Some applications only require access to certain resources at specific times orunder specific circ*mstances. For example:

• An application might require access to configuration data during startup, butmight not require that access once it's initialized.
• A supervisor application might periodically start background jobs where eachjob has different access requirements.

In such scenarios, using a single service account and granting it access to allresources goes against the principle of least privilege: At any point in time,the application is likely to have access to more resources than it actually needs.

To help ensure that the different parts of your application only have access to theresources they need, use the IAM Credentials API for temporary privilege elevation:

• Create dedicated service accounts for each part of the application or use caseand only grant the service account access to the necessary resources.
• Create another service account that acts as the supervisor. Grant the supervisorservice account the Service Account Token Creator roleon the other service accounts so that it can request short-lived access tokens for these service accounts.
• Split your application so that one part of the application serves as token brokerand only let this part of the application use the supervisor service accounts.
• Use the token broker to issue short-lived service accounts to the other partsof the application.

For help with creating short-lived credentials, seeCreate short-lived credentials for a service account.

Use Credential Access Boundaries to downscope access tokens

Google access tokens are bearer tokens, which means that their use isn't tiedto any particular application. If your application passes an access token to adifferent application, then that other application can use the token in the sameway your application can. Similarly, if an access token is leaked to a bad actor,they can use the token to gain access.

Because access tokens are bearer tokens, you must protect them from being leakedor becoming visible to unauthorized parties. You can limit thepotential damage a leaked access token can cause by restricting theresources it grants access to. This process is called downscoping.

Use Credential Access Boundariesto downscope access tokens whenever you pass an access token to a different application,or to a different component of your application. Set the access boundary so thatthe token grants enough access to the required resources, but no more.

Use role recommendations to identify unused permissions

When you first deploy an application, you might be unsure about which roles andpermissions the application really needs. As a result, you might grant theapplication's service account more permissions that it requires.

Similarly, an application's access requirements might evolve over time, and someof the roles and permissions you granted initially might not be needed.

Userole recommendationsto identify which permissions an application is actually using, and whichpermissions might be unused. Adjust the allow policies of affected resources tohelp ensure that an application isn't granted more access than it actuallyneeds.

Use lateral movement insights to limit lateral movement

Lateral movement is when a service account in one project has permission toimpersonate a service account in another project. For example, a serviceaccount might have been created in project A, but have permissions toimpersonate a service account in project B.

These permissions can result in a chain of impersonations across projects thatgives principals unintended access to resources. For example, a principal couldimpersonate a service account in project A, and then use that service account toimpersonate a service account in project B. If the service account in project Bhas permission to impersonate other service accounts in other projects in yourorganization, the principal could continue to use service account impersonationto move from project to project, gaining permissions as they go.

Recommender provides lateral movementinsightsto help you mitigate this issue. Lateral movement insights identify roles thatallow a service account in one project to impersonate a service account inanother project. To learn how to view and manage lateral movement insightsdirectly, see Manage lateral movementinsights.

Some lateral movement insights are associated with role recommendations. Youcan apply those recommendations to reduce lateral movement across your projects.To learn how, see Review and applyrecommendations.

Protect against privilege-escalation threats

A service account that hasn't been granted any roles, does not have access to anyresources, and isn't associated with any firewall rulesis typically of limited value. After you grant a service account access to resources,the value of the service account increases: The service account becomes more usefulto you, but it also becomes a more attractive target for privilege-escalation attacks.

As an example, consider a service account that has full access to a Cloud Storage bucketwhich contains sensitive information. In this situation, the service account iseffectively as valuable as the Cloud Storage bucket itself: Instead of trying to accessthe bucket directly, a bad actor might attempt to take control of theservice account. If that attempt is successful, the bad actor can escalate theirprivileges by impersonating the service account, which in turn gives them accessto the sensitive information in the bucket.

Privilege-escalation techniques involving service accounts typically fall into these categories:

• Authenticating as the service account: You might inadvertently grant auser permission to impersonate aservice account or to create a service accountkey for a serviceaccount. If the service account is more privileged than the user themselves,then the user can authenticate as the service account to escalate theirprivileges and gain access to resources they otherwise couldn't access.

• Using resources that have an attached service account: If a user haspermission to access and modify CI/CD pipelines, VM instances, or otherautomation systems that have attached service accounts, then they might beable to perform actions using those resources' attached service accounts. Asa result, even though they don't have permission to impersonate the serviceaccount, they might still be able to use the service account's permissionsto perform actions that they wouldn't be allowed to perform themselves.

  For example, if a user has SSH access to a Compute Engine VMinstance, then they can run code on the instance to access any resource thatthe instance's attached service account can access.

• Allow policy, group, or custom role modifications: A user who doesn'thave access to a privileged service account might still have permission tomodify the allow policies of the service account, enclosingGoogle Cloud project, or folder. The user could then extend one of theseallow policies to grant themselves permission to (directly or indirectly)authenticate as the service account.

The following sections provide best practices for protecting service accountsfrom privilege-escalation threats.

Avoid letting users authenticate as service accounts that are more privileged than the users themselves

By impersonating a service account, a user gains access to some or all of theresources the service account can access. If the service account has moreextensive access than the user, then it's effectively more privileged than theuser.

Granting a user permission to impersonate a more privileged serviceaccount can be a way to deliberately let users temporarily elevate theirprivileges—similar to using the sudo tool on Linux, or using processelevation on Windows. Unless you're dealing with a scenario where such temporaryelevation of privilege is necessary, it's best to avoid letting usersimpersonate a more privileged service account.

Users can also indirectly gain a service account's permissions by attaching itto a resource and then running code on thatresource. Running code in this way isn't service account impersonation becauseit only involves one authenticated identity (the service account's). However,it can give a user access that they wouldn't have otherwise.

Permissions that enable a user to impersonate a service account or attacha service account to a resource include the following:

• iam.serviceAccounts.getAccessToken
• iam.serviceAccounts.getOpenIdToken
• iam.serviceAccounts.actAs
• iam.serviceAccounts.implicitDelegation
• iam.serviceAccounts.signBlob
• iam.serviceAccounts.signJwt
• iam.serviceAccountKeys.create
• deploymentmanager.deployments.create
• cloudbuild.builds.create

Roles that contain some of these permissions include (but aren't limited to):

• Owner (roles/owner)
• Editor (roles/editor)
• Service Account User (roles/iam.serviceAccountUser)
• Service Account Token Creator (roles/iam.serviceAccountTokenCreator)
• Service Account Key Admin (roles/iam.serviceAccountKeyAdmin)
• Service Account Admin (roles/iam.serviceAccountAdmin)
• Workload Identity User (roles/iam.workloadIdentityUser)
• Deployment Manager Editor (roles/deploymentmanager.editor)
• Cloud Build Editor (roles/cloudbuild.builds.editor)

Before you assign any of these roles to a user, ask yourself:

• Which resources inside and outside the current Google Cloud project couldthe user gain access to by impersonating the service account?
• Is this level of access justified?
• Are there sufficient protections in place that control under which circ*mstancesthe user can impersonate the service account?

Don't assign the role if you can't confirm all questions. Instead, considergiving the user a different, less privileged service account.

Avoid letting users change the allow policies of more-privileged service accounts

Which users are allowed to use or impersonate a service account is captured bythe service account's allow policy. The allow policy can be modified or extendedby users who have the iam.serviceAccounts.setIamPolicy permission on theparticular service account. Roles that contain that permission include:

• Owner (roles/owner)
• Security Admin (roles/iam.securityAdmin)
• Service Account Admin (roles/iam.serviceAccountAdmin)

Roles that include the iam.serviceAccounts.setIamPolicy permission give a userfull control over a service account:

• The user can grant themselves permission to impersonate the service account,which gives the user the ability to access the same resources as the service account.
• The user can grant other users the same or a similar level of access to the service account.

Before you assign any of these roles to a user, ask yourself which resources insideand outside the current Google Cloud project the user could gain access to byimpersonating the service account. Don't let a userchange the allow policy of aservice account if the service account has more privileges than the user.

Don't let users create or upload service account keys

Service account keys letapplications or users authenticate as a service account. Unlike other forms ofservice account impersonation, using a service account key doesn't require anyprevious form of authentication – anyone who possesses a serviceaccount key can use it.

The net effect of using a service account key to authenticate is similar to theeffect of service account impersonation. If a user has access to a serviceaccount key, or give them permission to create a new service account key, theuser can authenticate as the service account and access all resources thatservice account can access.

Creatingor uploading a serviceaccount key requires the iam.serviceAccountKeys.create permission, which isincluded in the Service Account Key Admin (roles/iam.serviceAccountKeyAdmin)and Editor (roles/editor) roles.

Before you assign any role that includes the iam.serviceAccountKeys.createpermission to a user, ask yourself which resources inside and outside the currentGoogle Cloud project the user could gain access to by impersonating the serviceaccount. Don't let a user create service account keys for service accountsthat have more privileges than they do.

If your Google Cloud project doesn't require service account keys at all, applythe Disable service account key creation andDisable service account key uploadorganization policy constraints to the Google Cloud project or the enclosing folder.These constraints prevent all users from creating and uploading service account keys,including those with iam.serviceAccountKeys.create permission on a service account.

Don't grant access to service accounts at the Google Cloud project or folder level

Service accounts are resources and part of theresource hierarchy.You can therefore manage access to service accounts at any of the following levels:

• The individual service account
• The enclosing Google Cloud project
• A folder in the Google Cloud project's ancestry
• The organization node

Managing access at the Google Cloud project level or a higher level of the resourcehierarchy can help reduce administrative overhead, but can also lead to over-grantingof privileges. For example, if you grant a user the Service Account Token Creatorrole in a Google Cloud project, the user can impersonate any service accountin the Google Cloud project. Being able to impersonate any service account impliesthat the user can potentially gain access to all resources that those serviceaccounts can access, including resources outside that Google Cloud project.

To avoid such over-granting, don't manage access to service accounts at theGoogle Cloud project or folder level. Instead, individually manage access for each service account.

Don't run code from less protected sources on compute resources that have a privileged service account attached

When you attach a service account to a compute resource, such as a VM instanceor a Cloud Run application, processes running on that resource can usethe metadata server to request access tokens and IDtokens. These tokens let theprocess authenticate as the service account and access resources on its behalf.

By default, access to the metadata server isn't restricted to specific processesor users. Instead, any code that is executed on the compute resource can accessthe metadata server and obtain an access token. Such code might include:

• The code of your application.
• Code submitted by end users, if your application permits any server-side script evaluation.
• Code read from a remote source repository, if the compute resource is part of a CI/CD system.
• Startup and shutdown scripts served by a Cloud Storage bucket.
• Guest policies distributed by VM Manager.

If code is submitted by users or is read from a remote storage location, you mustensure that it's trustworthy and that the remote storage locations are at leastas well secured as the attached service account. If a remote storage location isless well protected than the service account, a bad actor might be able to escalatetheir privileges. They could do so by injecting malicious code that uses theservice account's privileges into that location.

Limit shell access to VMs that have a privileged service account attached

Some compute resources support interactive access and allow users to obtain shellaccess to the system. For example:

• Compute Engine lets you use SSH or RDP to log in to a VM instance.
• Google Kubernetes Engine lets you use kubectl exec to run a command or start a shell in a Kubernetes container.

If a VM instance has a privileged service account attached, then any user withshell access to the system can authenticate and access resources as the serviceaccount. To prevent users from abusing this capability to escalate theirprivileges, you must ensure that shell access is at least as well secured as theattached service account.

For Linux instances, you can enforce that SSH access is more restrictive thanaccess to the attached service account by using OS Login: To connect to a VM instancethat has OS Login enabled, a user must not only beallowed to use OS Login,but must also have the iam.serviceAccounts.actAs permission on the attached service account.

The same level of access control doesn't apply to VM instances that usemetadata-based keys or to Windows instances: Publishing anSSH key to metadata orrequesting Windows credentialsrequires access to the VM instance's metadata and the iam.serviceAccounts.actAspermission on the attached service account. However, after the SSH key has beenpublished or the Windows credentials have been obtained, subsequent logins are notsubject to any additional IAM permission checks.

Similarly, if a VM instance uses a custom Linux pluggable authentication modulefor authentication, or is a member of an Active Directory domain, it's possiblethat users who wouldn't otherwise have permission to authenticate as theservice account are allowed to log in. For more information, see Bestpractices for running Active Directory onGoogle Cloud.

Particularly for VM instances that don't use OS Login, consider gating shellaccess by Identity-Aware Proxy. Only grant theIAP-Secured Tunnel User role (roles/iap.tunnelResourceAccessor) to users whoshould be allowed to authenticate as the service account attached to the VMinstance.

Limit metadata server access to selected users and processes

When you attach a service account to a VM instance, workloads deployed on the VMcan access the metadata server to request tokens for the service accounts. Bydefault, access to the metadata server isn't limited to any specific process oruser on the VM: Even processes running as a low-privilege user, such as nobodyon Linux or LocalService on Windows, have full access to the metadata serverand can obtain tokens for the service account.

To limit metadata server access to specific users, configure the guest operatingsystem's host firewall to only allow these users to open outbound connections tothe metadata server.

On Linux, you can use the --uid-owner and --gid-owner options to set up aniptables rule that only applies to specific users or groups. On Windows,the Set-NetFirewallSecurityFilter command lets you customize afirewall rule so that it applies to selected users or groups.

Protect against information disclosure threats

Avoid disclosing confidential information in service account email addresses

To grant a service account access to a resource in another Google Cloud project,you can add a role binding to the resource's allow policy. Like the resourceitself, the allow policy is part of the other Google Cloud project and itsvisibility is also controlled by that other Google Cloud project.

Viewing allow policies is typically not considered a privileged operation. Manyroles include the required *.getIamPolicy permission, including the basicViewer role.

A user who can view an allow policy can also see the email addresses ofprincipals who have been granted access to the resource. In the case of serviceaccounts, email addresses can provide hints to bad actors.

For example, an allow policy might include a binding for a service account withthe email address jenkins@deployment-project-123.gserviceaccount.com. To a badactor, this email address not only reveals that there is a Google Cloud projectwith ID deployment-project-123, but also that the Google Cloud project runs aJenkins server. By choosing a more generic name such asdeployer@deployment-project-123.gserviceaccount.com, you avoid disclosing informationabout the type of software that you're running in deployment-project-123.

If you grant a service account access to resources in a Google Cloud projectthat has less tightly controlled access (such as a sandbox or a developmentGoogle Cloud project), make sure that the service account's email address doesn'tdisclose any information. In particular, don't disclose information that is confidential orthat could provide hints to attackers.

Protect against non-repudiation threats

Whenever you notice suspicious activity affecting one of your resources onGoogle Cloud, Cloud Audit Logs are an important source of information to findout when the activity happened and which users were involved.

Whenever Cloud Audit Logs indicate that activity was performed by a service account,that information alone might not be sufficient to reconstruct the full chainof events: You must also be able to find out which user or application caused theservice account to perform the activity.

This section contains best practices that can help you maintain a non-repudiableaudit trail.

Use service account keys only when there is no viable alternative

If you can't use more secure authentication methods,you might need to create a service account key for theapplication. However, authenticating with aservice account key introduces a non-repudiation threat. Cloud Audit Logs createsa log when a service account modifies a resource, but if the service account isauthenticated with a service account key, there is no reliable way to tell whoused the key. In comparison, authenticating as a service account byimpersonating the service account with user credentialslogs the principal who acted as the service account.

We recommend preventing the creation of service account keys by applying theDisable service account key creationorganization policy constraint to the Google Cloud project or the enclosingfolder. If you must useservice account keys for a scenario that can't be addressed with any of therecommended alternatives, grant an exception to thepolicy constraint, as narrowly as possible, and reviewbest practices for managing service account keys.

Enable data access logs for IAM APIs

To help you identify and understand service account impersonation scenarios,services such as Compute Engine include a serviceAccountDelegationInfo sectionin Cloud Audit Logs. This section indicateswhether the service account was being impersonated, and by which user.

Not all services include impersonation details in their Cloud Audit Logs.To record all impersonation events, you must alsoenable data access logs for the following APIs:

• Identity and Access Management (IAM) API in allGoogle Cloud projects that contain service accounts
• Security Token Service API in all Google Cloud projects thatcontain workload identity pools

By enabling these logs, you make sure that an entry is added to the Cloud Audit Logs whenevera user requests an access token or an ID token for a service account.

Ensure that CI/CD history can be correlated with Cloud Audit Logs

Service accounts are commonly used by CI/CD systems to perform deployments aftera code change has been successfully verified and approved for deployment. Typically,CI/CD systems maintain a history of events that lead to a deployment. This historymight include the IDs of the corresponding code reviews, commits, and pipeline runs,and information about who approved the deployment.

If a deployment modifies any resources on Google Cloud, then these changesare tracked in the Cloud Audit Logs of the respective resources.Cloud Audit Logs contain information about the user or service accountthat initiated the change. But in a deployment triggered by a CI/CD system,the service account itself is often insufficient to reconstruct the entire chain ofevents that led to the change.

To establish a consistent audit trail across your CI/CD system and Google Cloud,you must ensure that Cloud Audit Logs records can be correlated with events inthe CI/CD system's history. If you encounter an unexpected event in the Cloud Audit Logs,you can then use this correlation to determine whether the change was indeed performed by theCI/CD system, why it was performed, and who approved it.

Ways to establish a correlation between Cloud Audit Logs records and events inthe CI/CD system's history include:

• Log API requests performed by each CI/CD pipeline run.
• Whenever the API returns an operation ID, record the ID in the CI/CD system's logs.

• Add a X-Goog-Request-Reason HTTP headerto API requests and pass the ID of the CI/CD pipeline run. Terraform canautomatically add this header if you specify a request reason.

  Alternatively, embed the information in the User-Agent header so that it is captured in Cloud Audit Logs.

To help ensure non-repudiability, configure log files and commit histories so that theyare immutable and a bad actor can't retroactively conceal their traces.

Create custom log entries for individual users of an application

Service accounts are also useful for applications in which a user authenticateswith a custom authentication scheme, then indirectly accesses Google Cloudresources. These applications can confirm that the user is authenticated andauthorized, then use a service account to authenticate to Google Cloudservices and access resources. However, Cloud Audit Logs will log that theservice account accessed a resource, not which user was using your application.

To help trace that access back to the user, design application logic to write a custom log entry each time a user accesses a resource and correlate the custom log entries with Cloud Audit Logs.

What's next

• Understand best practices for managing service account keys.
• Review our best practices for using service accounts in deployment pipelines.
• Learn about best practices for using workload identity federation.