Webhook for Workload Identity Federation on Kubernetes clusters outside GCP is now available

Shingo Omura


Japanese article is available here.

I am Shingo Omura, a Machine Learning Platform Engineer.


We have released an implementation of Admission Webhook that enables the secure use of Google Cloud APIs from Kubernetes clusters outside of GCP (Google Cloud Platform). The Admission Webhook uses the Workload Identity Federation functionality to authenticate with a token associated with the ServiceAccount of the external Kubernetes cluster.

With this webhook, you can use Google Cloud APIs more securely from external Kubernetes clusters than before, as shown below.

Previous From Now On
  • GCP Service Account key needs to be issued.
  • GCP Service Account keys must be managed as Secret resources in Kubernetes.
  • Need to mount Secret to Pod in Manifest explicitly
  • If GCP Service Account keys are not rotated, the impact of a breach can be significant (recently, credentials for Cloud API have been targeted in supply chain attacks)
  • No need to issue GCP Service Account keys
  • No need to store GCP Service Account keys
    as Sectet resources in Kubernetes
  • Kubernetes ServiceAccount can be used directly for Google Cloud API authentication
  • The credential used in this scenario is temporary (with an expiration date)
  • And, since it is automatically rotated, the impact of leakage can be minimized

What is Workload Identity Federation?

In a nutshell, Workload Identity Federation (WIF) allows users to access Google Cloud APIs using external identities provided by services other than GCP. Before this mechanism was provided, as mentioned in the previous section, it was necessary to manage indefinite GCP Service Account keys (or to build a rotation mechanism on the user side), and the risk of leakage was high. Now that this feature is available, if you provide an external ID provider (AWS, Azure Active Directory, Okta, OIDC, SAML 2.0, etc.) that is supported by WIF, you can use the credentials issued by the external ID provider to borrow the authority of a GCP Service Account temporarily. Technically, the credentials issued by the external ID provider are exchanged with the Google Cloud API credentials via a security token service (STS) that follows the OAuth 2.0 Token Exchange specification.

Some readers can remember the article “Enabling keyless authentication from GitHub Actions” was in trend on this topic. Please also refer to the articles for a detailed explanation of how the Workload Identity Federation works (these articles are in Japanese).

Make your Kubernetes cluster an external identity provider

The Kubernetes ServiceAccount Token (Bound Service Account Token) is actually issued by the Control Plane as an OIDC ID Token, and the Kubernetes API Server has the ability to expose information about the OIDC Provider (called Service Account Issuer Discovery). The Kubernetes API Server has a function (called Service Account Issuer Discovery) to expose information about OIDC Providers, so it can act as a limited OIDC Provider to the extent that STS can verify the ServiceAccount Token. If the Kubernetes cluster is deployed on a private network, such as on-premises, two endpoints are required to validate the Token when exchanging Kubernetes ServiceAccount Tokens with STS (OIDC Dicovery, and OIDC JWKs) can be exposed as accessible from STS.

Then, on the GCP side, you can use WIF by configuring a Workload Identity Pool and Workload Identity Pool Provider corresponding to the external identity provider (Kubernetes cluster), and granting the external identity (Kubernetes ServiceAccount) borrowing privileges for the GCP service account.

For more information, see “Kubernetes Service Account As Multi-Cloud Identity“(video) presented at the Cloud Native Security Conference 2022 (The slide is in Japanese only).

GCP Workload Identity Federation Webhook

If you set up a Kubernetes cluster as an external identity provider, you can use WIF, but some configuration is required on the client (pod side), too. Specifically, the Google Cloud SDK must be configured to use the Kubernetes ServiceAccount Token as the Federated Identity (exchanging the ServiceAccount Token at STS before accessing the API). This Webhook automates this process for you. The concept is almost the same as Amazon EKS Pod Identity Webhook (Webhook used in IRSA) and Azure AD Workload Identity.

As shown below, simply annotate the Kubernetes ServiceAccount with the corresponding Workload Identity provider and the GCP Service Account you wish to borrow, and just create a Pod with the Kubernetes ServiceAccount. Then, the Containers in the Pod will automatically use GCP Service Account privileges.

Please refer to the README for specific information on what information is injected.


The major Public Clouds (AWS, GCP, Azure) provide Identity Federation functionality. In addition, each Managed Kubernetes provides the ability to use the Kubernetes ServiceAccount as the Identity for its Cloud API.

Identity Federation Feature Support in Managed Kubernetes
AWS Identity providers and federation IAM roles for service accounts – Amazon EKS 
GCP Workload identity federation Use Workload Identity – GKE 
Azure Azure AD Workload Identity Use an Azure AD workload identities (preview) on Azure Kubernetes Service (AKS)

However, Kubernetes clusters running externally or On-Premise, we need to deploy a Webhook to inject Cloud API client configuration for using Identity Federation functionality. AWS and Azure published them in OSS. But we can’t find one for GCP(Anthos is supported at the product level, so there is no need to deploy a webhook on your own). Therefore, PFN had developed the webhook in-house, but now we have made it public because we consider it highly public.

ククラウド外のKubernetes ServiceAccountを
Federated Identityとして利用するためのWebhook(OSS)
AWS Amazon EKS Pod Identity Webhook
※EKS Anywhere supported this feature at the product level, so there is no need to deploy a Webhook.
GCP GCP Workload Identity Federation Webhook(今回公開)
Anthos supported this feature at the product level, so there is no need to deploy a Webhook.
Azure Azure AD Workload Identity Azure(Official)


PFN’s on-premise machine learning platform provides a feature that Kubernetes ServiceAccount can be used as a Federated Identity for various Public Clouds (AWS, GCP, Azure). We published the result in the talk “Kubernetes Service Account As Multi-Cloud Identity” at Security Conference 2022.

And a webhook implementation for GCP Workload Identity Federation which had developed in-house at PFN is now available as OSS.

We hope you will try it and give us feedback.

We’re Hiring!!

PFN’s Machine Learning Platform team is looking for an engineer. If you are interested in building & operating such cloud integration or on-premise machine learning clusters, we look forward to hearing from you!

Machine Learning Platform Engineer (Infrastructure)

  • Twitter
  • Facebook

Archive List