Keyless API authentication—Better cloud security through workload identity federation, no service account keys necessary

Organizations often have applications that run on multiple platforms, on-premises or cloud. For such applications that call Google Cloud Platform (GCP) APIs, a common challenge admins face is securing long-lived service account keys used to authenticate to GCP. Examples of such applications might include:

• Analytics workloads running on AWS or Azure that access sensitive datasets stored in Google Cloud Storage 

• CI/CD pipelines that use external tools such as Terraform to provision projects and VMs on GCP 

• Microservice-based apps running on GKE that connect to one or more GCP services.  

Since these applications rely on service account keys to access GCP APIs, you need to create and manage these credentials and have safeguards in place to ensure that long-lived service keys are well protected, securely distributed, and frequently rotated. If these credentials are compromised, a bad actor can use them to access your resources and data, and put your business at risk. Managing service account keys can become even more challenging as your organization’s cloud consumption and deployment of multi-cloud applications grows, putting you in the unenviable position of having to self-manage thousands of service account credentials or invest in third-party solutions to safeguard these service account keys.

The best way to alleviate the challenges around service account keys is not to use them at all - and with workload identity federation, a new feature on Google Cloud, you can do just that.

What is workload Identity federation and how do I set it up?

Workload identity federation is a new keyless application authentication mechanism that allows your workloads running on-premises, in AWS, or in Azure to federate with an external Identity provider (IdP) and call Google Cloud resources without using a service account key. Your workloads instead call our security token service (STS) endpoint to exchange the authentication token they obtained from the IdP for a short-lived GCP access token. They then use this access token to impersonate a service account and inherit the permissions of the service account to access GCP resources.

Here are the steps to set up workload identity Federation:

1 .Create a workload identity pool resource object in your GCP project. The workload identity Pool is a new component built to facilitate this keyless federation mechanism. The pool acts as a container for your collection of external identities.

2. Connect one or more of your IdPs to the workload identity Pool. The IdP can be an AWS or Azure account(s) or provider(s) that support OIDC protocol (SAML is coming soon).

3. Grant the pool access to resources by defining two IAM policies:

1. A policy granting a service account access to desired resources. You can create a new service account or re-use an existing service account. 

2. A policy that allows identities from the pool to impersonate the service account. Detailed information on creating these policies are available in our documentation.

4. Authenticate your workloads to the STS endpoint, impersonate the service account, and have them call the desired GCP APIs.

More detailed information on how to set up workload identity federation and configure policies can be found here. 

Integration with authentication client libraries

We’ve provided extensive client library support in many languages to help your application developers simplify and secure the authentication process with minimal coding. We highly-recommend you use them. 

Here’s an example of how developers can can start using workload identity pools with the Google Cloud Client libraries in two steps:

Generate the credentials configuration file for your workload identity pool provider:

Set the GOOGLE_APPLICATION_CREDENTIALS environment variable on your VM to point to the generated credentials config file.

You can now start using workload identity pools to call Google APIs as illustrated in this Python snippet:

You can use custom attributes (claims) from the IdP to define fine-grained IAM access policy to allow or deny your workloads access to resources and audit their calls using Cloud Audit Logs.

Improving your cloud security posture

Moving from service account keys to the keyless application authentication mechanism enabled by workload identity federation can help you reduce the risks associated with managing long-lived keys for application authentication across your environment. With this new capability, developers can build more secure applications and better protect access to GCP services. To learn more about workload identity federation, take a look at our documentation.