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

TL;DR

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.

https://github.com/pfnet-research/gcp-workload-identity-federation-webhook

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).

• 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).

GCP Workload Identity Federation Webhook

公開した背景

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.

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.

Summary

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.

https://github.com/pfnet-research/gcp-workload-identity-federation-webhook

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)