Google Cloud Workload Identity Federation with Okta

Introduction

Businesses with on-premise applications (or those running on another cloud) that want to call Google Cloud APIs have traditionally used Google Cloud service account keys. Service account keys are credentials which by default do not expire. Such keys, if not managed correctly, can pose a security risk. Workload identity federation (“WIF”) provides a better approach for providing access to non-Google Cloud applications.

WIF has the concept of pools which represent collections of identities. You associate pool providers which represent identity providers to pools. This article introduces using WIF with Okta as the trusted identity provider. A client application obtains a token from a trusted identity provider and then uses WIF to exchange that token for short term Google Cloud OAuth 2.0 tokens which can then be used to call Google Cloud APIs rather than using a service account key.

Upfront acknowledgements

I want to thank my colleagues for helping me to understand this topic in more depth. One of my colleagues wrote an article about this topic. Another colleague created a GitHub repository to help demo it. A third colleague helped we with debugging efforts.

So why am I writing this article given all the work my colleagues have already done? Mostly, because I found myself needing more guidance and I wanted to dig a little deeper into the Okta configuration and better understand the APIs as well as the RFCs that apply. I have found that reading RFCs is extremely helpful in understanding what is happening at each step of the process

The scenario

Take a look at the diagram below. The diagram shows a macOS client workstation. The client wants to create a bucket in Google Cloud storage. Traditionally, the client would need access to a Google Cloud service account key that that has permissions to create a bucket. If this service account key were to somehow become public, anyone having the key would be able to create a bucket. Rather than taking this approach, the client will reach out to Okta, an identity provider, to obtain a token and exchange it for short term Google Cloud credentials and use those credentials to create the bucket.

Here’s how it works.

1. The client workstation application requests a token from their Okta service.
2. The Okta service issues a token. This step and the previous step implement a Client Credentials Grant as mentioned in RFC 6749, the OAuth 2.0 authorization framework.
3. The workstation then initiates an exchange of the Okta token with Google Cloud using the Secure Token Service (STS) API.
4. Workload identity federation validates the Okta token.
5. Workload identity federation returns an access token from the STS API. This step and the two previous steps implement a token exhange per RFC 8693, the OAuth 2.0 Token Exchange specification. The returned STS token is a federated token that cannot be used directly.
6. The workstation then initiates an exchange of the STS token for a service account token using the IAM credentials API.
7. The IAM credentials API returns a service account access token. At this point, the client now has a token that allows the client to impersonate the service account.
8. The workstation then uses the service account access token to call the Google Cloud Storage API to create the bucket. Since the client only has short-term credentials which by default last only one hour, the risk from a compromised key is greatly reduced.

Want to learn more?

If what you’ve read so far looks interesting, you can dive deeper and actually build this. Check out my repository for more info!