GCP外のKubernetesクラスタでWorkload Identity Federationを使えるWebhookを公開しました

English article is available here.

機械学習プラットフォームエンジニアの大村です。

TL;DR

GCP(Google Cloud Platform)外のKubernetesクラスタからGoogle Cloud APIの安全な利用を可能とするAdmission Webhookの実装を公開しました！Workload Identity Federationの機能を利用することにより外部KubernetesクラスタのServiceAccountに紐付くトークンで認証しています。

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

このWebhookを使うことで、下記のように以前と比べて外部のKubernetesクラスタからよりセキュアにGoogle Cloud APIを利用できます。

これまで	これから
サービスアカウントキーを発行する必要がある サービスアカウントキーをSecretとして管理する必要がある Manifestで明示的にSecretをPodにマウントする必要がある サービスアカウントキーはローテーションを行わない場合、漏洩時の影響が大きい(最近Supply Chain攻撃などでもパブリッククラウドの認証情報は狙われている)	サービスアカウントキーを発行する必要がない サービスアカウントキーをKubernetesリソースとして保存する必要がない Kubernetes ServiceAccountを直接認証に利用できる GCP認証情報は一時的(有効期限付き) かつ、自動的にローテーションされるので漏洩に対してより安全

Workload Identity Federationとは

Workload Identity Federation(以下WIF)は一言で言うと、「GCP以外のサービスが提供する外部IDを用いて、Google Cloud APIにアクセスできる」機能です。この仕組が提供される以前は前節でも紹介したとおり、無期限のサービスアカウントキーを管理しなくてはならず（もしくはユーザ側でローテーションの仕組みを構築する必要があり）、漏洩時のリスクが大きい状態でした。この機能が提供されたことで、WIFが対応している外部IDプロバイダ(AWS, Azure Active Directory, Okta, OIDC, SAML 2.0等)を提供すれば、外部IDプロバイダの発行した認証情報を使って、GCPサービスアカウントの権限を一時的に借用させることができます。技術的にはOAuth 2.0 Token Exchangeの仕様に従うセキュリティトークンサービス(STS)を介して、外部IDプロバイダの発行した認証情報をGoogle Cloud APIの認証情報と交換します。

最近だと、GitHub Actions からのキーなしの認証の有効化で紹介されて注目を集めたのが記憶に新しい方もいると思います。Workload Identity Federationの仕組みについては詳しく説明している記事が公開されていますのでそちらもあわせて参照ください。

• Workload Identity Federationを図で理解する – Carpe Diem
• Workload Identity Federationとは / 社内IDaaS勉強会資料共有
• Workload Identity FederationをGitHub Actionsで利用する

Kubernetesクラスタを外部IDプロバイダにする

Kubernetes ServiceAccount Token(Bound Service Account Token)は、実はOIDC ID TokenとしてControl Planeが発行しており、Kubernetes API ServerはOIDC Providerに関する情報をexposeする機能(Service Account Issuer Discoveryと呼ばれます)を持っているので、STSがServiceAccount Tokenを検証できる範囲で、限定的なOIDC Providerとして振る舞う事ができます。Kubernetesクラスタがオンプレミスなどのプライベートネットワークにデプロイされている場合は、STSでKubernetes ServiceAccount Tokenを交換する際にTokenの検証を行うために必要な2つのエンドポイント(OIDC Dicovery, OIDC JWKs)をSTSからアクセス可能な状態で公開する事ができます。

あとは、GCP側でもKubernetesクラスタ(外部IDプロバイダ)に対応する、 Workload IdentityプールとWorkload Identityプールプロバイダを構成し、外部ID(Kubernetes ServiceAccount)にGCPサービスアカウントの借用権限を付与すれば、WIFを利用できます。

詳細はCloud Native Security Conference 2022 で発表した“Kubernetes Service Account As Multi-Cloud Identity”(video)で解説しています。

GCP Workload Identity Federation Webhook

Kubernetesクラスタを外部IDプロバイダとして設定できればWIFが利用できますが、クライアント(Pod側)でもいくつか設定が必要になります。具体的には、Kubernetes ServiceAccount TokenをFederated Identityとして利用する(STSでServiceAccount Tokenを交換してからAPIアクセスする)ようにGoogle Cloud SDKの設定を行う必要があります。それを自動化してくれるのがこのWebhookです。コンセプトはAmazon EKS Pod Identity Webhook(IRSAで使われているWebhook)やAzure AD Workload Identityとほぼ同じです。

下記のようにServiceAccountに、対応するWorkload Identityプロバイダ、借用したいGCPサービスアカウントをannotationしておいて、そのServiceAccountでPodを作成するだけで、Pod内のContainerは自動的にGCPサービスアカウント権限を借用することができます。

具体的にどういう情報が注入されるかはREADMEを御覧ください。

公開した背景

メジャーなPublic Cloud(AWS, GCP, Azure)ではIdentity Federationの機能が提供されています。また、それぞれのManaged Kubernetesでは、Kubernetes ServiceAccountをそのCloud APIのIdentityとして利用できる機能が提供されています。

ですが、他のクラウドやオンプレミスのKubernetesクラスタでは、Kubernetes ServiceAccountをFederated Identityとして利用する際に設定を注入してくれるWebhookが必要です。AWS、Azureについては公開されていますが、GCPについては公開されていません(Anthosは製品レベルで対応しているため自前でWebhookデプロイ不要)。そのため、PFNではWebhookを内製していましたが、公共性が高いと考え、今回公開しました。

さいごに

PFNのオンプレミスの機械学習プラットフォームでは、Kubernetes ServiceAccountを各種Public Cloud(AWS, GCP, Azure)のFederated Identityとして利用できる環境を構築しており、Cloud Native Security Conference 2022 にて“Kubernetes Service Account As Multi-Cloud Identity”として成果を発表しています。今回、その際に、PFNで内製していたGCP Workload Identity Federation向けのWebhook実装として

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

を公開しました。是非使ってみていただいてフィードバックをいただけると嬉しいです。

We’re Hiring!!

PFNの機械学習プラットフォームチームではエンジニアを募集しています。こうしたクラウド連携や、オンプレミスの機械学習クラスタの構築&運用に興味のある方、ご応募お待ちしています！

Machine Learning Platform Engineer/機械学習プラットフォームエンジニア (Infrastructure)