Google Cloud provides service accounts to act as identities for workloads in production environments. Instead of granting access to a workload directly, you grant access to a service account, then have the workload use the service account as its identity.
There are several ways that you can configure service accounts as identities for workloads. Which methods you can use depends on where your workloads are running.
Workloads on Google Cloud
If you're running workloads on Google Cloud, you can use the following methods to configure identities for your workloads:
- Attached service accounts
- Managed workload identities (for workloads that run on Compute Engine only)
- Workload Identity (for workloads that run on Google Kubernetes Engine only)
- Service account keys
Attached service accounts
For some Google Cloud resources, you can specify a user-managed service account that the resource uses as its default identity. This process is known as attaching the service account to the resource, or associating the service account with the resource.
When code running on the resource accesses Google Cloud services and resources, it uses the service account attached to the resource as its identity. For example, if you attach a service account to a Compute Engine instance, and the applications on the instance use a client library to call Google Cloud APIs, those applications automatically use the attached service account for authentication and authorization.
In most cases, you must attach a service account to a resource when you create that resource. After the resource is created, you cannot change which service account is attached to the resource. Compute Engine instances are an exception to this rule; you can change which service account is attached to an instance as needed.
To learn more, see Attach a service account to a resource.
Managed workload identities
Managed workload identities let you bind strongly attested identities to your Compute Engine workloads. You can use managed workload identities to authenticate your workloads to other workloads using mTLS, but they cannot be used for authenticating to Google Cloud APIs.
To learn more about managed workload identity, see Managed workload identities overview.
To learn more about using managed workload identities with Compute Engine workloads, see Authenticate workloads to other workloads over mTLS.
GKE Workload Identity
For workloads running on GKE, Workload Identity allows a Kubernetes service account in your GKE cluster to act as an IAM service account. Pods that use the configured Kubernetes service account automatically use the IAM service account as their identity when accessing Google Cloud APIs. Using Workload Identity lets you assign distinct, fine-grained identities and authorization for each application in your cluster.
To learn more about GKE Workload Identity, see Workload identity federation for GKE.
Service account keys
A service account key lets a workload authenticate as a service account, then use the service account's identity for authorization. Service account keys are a security risk if not managed correctly. You should choose a more secure alternative to service account keys whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by Best practices for managing service account keys. If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see Managing secure-by-default organization resources.
External workloads
If you're running workloads outside of Google Cloud, you can use the following methods to configure identities for your workloads:
- Workload identity federation
- Service account keys
Workload identity federation
Workload identity federation lets you use credentials from external identity providers like AWS and Azure Active Directory to generate short-lived credentials, which workloads can use to temporarily impersonate service accounts. Workloads can then access Google Cloud resources, using the service account as their identity.
Workload identity federation is the preferred way to configure identities for external workloads.
To learn more about workload identity federation, see Workload identity federation.
Service account keys
A service account key lets a workload authenticate as a service account, then use the service account's identity for authorization. Service account keys are a security risk if not managed correctly. You should choose a more secure alternative to service account keys whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by Best practices for managing service account keys. If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see Managing secure-by-default organization resources.
Local development
If you're developing in a local environment, you can configure workloads to use your user credentials for authentication and authorization. For more information, see Local development environment in the authentication documentation.
What's next
- Learn how to set up authentication by using service accounts.
- Learn how to set up authentication for a local development environment.
- Learn how to grant service accounts access to resources.