Extending a platform or service to support workload identity federation
When we have an AWS or Azure workload that needs to access Google Cloud resources, we can let the workload use workload identity federation to authenticate in a key-less fashion. But workload identity federation isn’t limited to authenticating workloads between cloud providers. There are many other scenarios where it can be interesting to use workload identity federation, for example:
- A CI/CD system that deploys or manages Google Cloud resources.
- A business intelligence or reporting application that analyzes data stored in BigQuery.
- Robotic process automation (RPA) workflows that involve Google Cloud resources.
Some of these applications might run on premises while others might be SaaS-based. In both cases, using workload identity federation can help us avoid the perils of service account keys.
But what’s necessary for a platform or service to be compatible with workload identity federation? And as a vendor of the platform or service, what’s required to add support for federation and what are common pitfalls to avoid?
In a new article published on the Google cloud website, Let customers access their Google Cloud resources from your product or service, I’m trying to answer these questions. The article details the requirements an application must meet to be compatible, and describes a number of best practices that vendors can implement, such as:
- Distinguish between identity and access tokens.
- Expose ID tokens in a way that’s compatible with client libraries.
- Use tenant-specific issuer URLs.
- Allow users to specify the ID token audience.
- Use immutable, non-reusable identifiers in ID token claims.
- Include context information in ID tokens.
For a full list of articles I’ve published on the Google Cloud website, see Articles on cloud.google.com.