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.