Google Cloud 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:

For a full list of articles I’ve published on the Google Cloud website, see Articles on

Any opinions expressed on this blog are Johannes' own. Refer to the respective vendor’s product documentation for authoritative information.
« Back to home