Choose the best way to use and authenticate service accounts on Google Cloud
Johannes Passing
Solutions Architect
Vignesh Rajamani
Product Manager, Google Cloud
A fundamental security premise is to verify the identity of a user before determining if they are permitted to access a resource or service. This process is known as authentication. But authentication is necessary for more than just human users. When one application needs to talk to another, we need to authenticate its identity as well. In the cloud, this is most frequently accomplished through a service account.
Service accounts represent non-human users and on Google Cloud are managed by Cloud Identity and Access Management (IAM). They are intended for scenarios where an application needs to access resources or perform actions under its own identity. For example, an application that runs on a VM instance might need access to a Cloud Storage bucket that is configured to store its data.
Unlike normal users, service accounts cannot authenticate using a password or single sign-on (SSO). There are a variety of authentication methods that service accounts can employ instead, and it’s important to use the right one based on your needs. The following guidelines can help make sure you choose the best way to authenticate service accounts.
Only use service accounts where appropriate
Before you jump to the conclusion that you need a service account, ask yourself whether the application is acting on its own behalf or on the end user’s behalf:
An application that continuously gathers metrics and stores them in a Cloud Storage bucket acts on its own behalf—it’s a background job that runs unattended, with no end user involved.
An application that lets a user access their personal documents is not acting on its own behalf, but on behalf of the end user.
Whenever an application is acting on behalf of an end user, using a service account might not be the right choice. Instead, it’s better to use an OAuth consent flow to request the end user’s consent, and then let the application act under their identity. By using OAuth, you ensure that:
End users can review which resources they are about to grant the application access to, and can explicitly express or deny their consent.
Users can revoke their consent on their My Account page at any time.
No service account gets unfettered access to user data.
During your daily work, you might use tools such as gcloud, gsutil or terraform. It’s you who runs these tools, so the tools should also use your credentials. Instead of using a service account key to run these tools, let them use your credentials by running gcloud auth login (for gcloud and gsutil) or gcloud auth application-default login (for terraform and other third-party tools).
Limiting the use of service accounts and service account keys to situations in which they're absolutely necessary keeps user data more secure, reduces the chance of unauthorized activity, and makes it easier to use audit logs to determine which users performed certain operations.
Use attached service accounts when possible
For applications deployed on Google Cloud that need to use a service account, attach the service account to the underlying compute resource. By attaching a service account, you enable the application to obtain tokens for the service account and to use these tokens to access Google Cloud APIs and resources.
To obtain access tokens in the application, use the Google Cloud client libraries if possible. The client libraries automatically detect if the application is running on a compute resource with an attached service account.
In situations where using the client libraries is not practical, adjust your application to programmatically obtain tokens from the metadata server. Compute resources that support access to the metadata server include:
For a full list of compute resources that let you attach a service account, see Managing service account impersonation.
Use Workload Identity to attach service accounts to Kubernetes pods
If you use Google Kubernetes Engine (GKE) you might be running a combination of different applications on a single GKE cluster. The individual applications are likely to differ in which resources and APIs they need access to.
If you attach a service account to a GKE cluster or one of its node pools, then by default, all pods running on the cluster or node pool can impersonate the service account. Sharing a single service account across different applications makes it difficult to assign the right set of privileges to the service account:
If you only grant access to resources that all applications require, then some applications might fail to work because they lack access to certain resources.
If you grant access to all resources that any particular application needs, then you might be over-granting access.
A better approach to manage resource access in a GKE environment is to use Workload Identity, which lets you associate service accounts with individual pods:
Do not attach service accounts to GKE clusters or node pools.
In Cloud IAM, create a dedicated service account for each Kubernetes pod that requires access to Google APIs or resources.
In GKE, create a Kubernetes service account for each Kubernetes pod that requires access to Google APIs or resources and attach it to the pod.
Use Workload Identity to create a mapping between the service accounts and their corresponding Kubernetes service accounts.
Use Workload Identity federation to use services accounts for applications not running on Google Cloud
If your application runs on-premises or on another cloud provider, then you cannot attach a service account to the underlying compute resources. However, the application might have access to environment-specific credentials such as:
Azure AD access tokens
OpenID access tokens or ID tokens issued by an on-premises identity provider like AD FS or KeyCloak
If your application has access to one of these credentials and needs access to Google Cloud APIs or resources, use workload identity federation.
Workload identity federation lets you create a one-way trust relationship between a Google Cloud project and an external identity provider. Once you’ve established that trust, applications can use credentials issued by the trusted identity provider to impersonate a service account by following a three-step process:
Obtain a credential from the trusted identity provider, for example an OpenID Connect ID token.
Use the STS API to exchange the credential against a short-lived Google STS token.
Use the STS token to authenticate to the IAM Credentials API and obtain short-lived Google access tokens for a service account.
By using workload identity federation, you can let applications use the native authentication mechanisms that the external environment provides, and you avoid having to store and manage service account keys.
Use service account keys only if there is no viable alternative
Occasionally, you might encounter a situation where attaching a service account is not possible, and using Workload Identity or Workload Identity federation aren’t viable options either. For example, one of your on-premises applications might need access to Google Cloud resources, but your on-premises identity provider isn’t compatible with OpenID Connect (or SAML 2.0, which we’ll soon add support for), and therefore cannot be used for Workload Identity federation.
In situations where other authentication approaches are not viable (and only in those situations), create a service account key for the application. A service account key lets an application authenticate as a service account, similar to how a user might authenticate with a username and password. Service account keys must be kept secret and protected from unauthorized access, so store them in a secure location such as a key vault and rotate them frequently.
As an organization administrator you might want to control which users in your organization can use service account keys. This can be done using the service account key organization policies.
Decision time
Authenticating with service accounts is powerful, but it’s by no means the only way to do so, and should only be used if other approaches aren’t a good fit. If you’re still unsure about which authentication approach is best for your application, consult the following flowchart:
For more details on using and securing service accounts, see Best practices for using and managing service accounts and Best practices for securing service accounts in our product documentation.
