Google Cloud | Security AI

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:

gcloud iam workload-identity-pools create-cred-config \
# Workload identity pool provider resource name.
projects/project-number/locations/global/workloadIdentityPools/pool-id/providers/aws-pid \
# Service account to impersonate.
--service-account \
# Generate configuration file for AWS VM.
--aws \
# Output file location.
--output-file credentials.json

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

export GOOGLE_APPLICATION_CREDENTIALS=/absolute/path/to/credentials.json

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

from import storage
import google.auth
credentials, project = google.auth.default(scopes=scopes)
# Automatically initializes credentials using credentials.json config file.
client = storage.Client(project=project, credentials=credentials)
# Lookup bucket information.
bucket = client.get_bucket('test-gcs-bucket')
print("Bucket {} retrieved.".format(

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.

By: Vignesh Rajamani (Product Manager, Google Cloud)
Source: Google Cloud Blog

For enquiries, product placements, sponsorships, and collaborations, connect with us at We'd love to hear from you!

Our humans need coffee too! Your support is highly appreciated, thank you!

Previous Article
Google Cloud | Financial Services

Fintech Startup, Branch Makes Data Analytics Easy With BigQuery

Next Article
Google Cloud | Dunzo

Dunzo: How Transforming The Delivery Experience With Google Maps Platform Helped Reduce Support Calls By 90%

Related Posts