Webhook for Workload Identity Federation on Kubernetes clusters outside GCP is now available
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|
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).
- Workload Identity Federationを図で理解する – Carpe Diem
- Workload Identity Federationとは / 社内IDaaS勉強会資料共有
- Workload Identity FederationをGitHub Actionsで利用する
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).
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.
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.
|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.
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!