Open ID Connect対応IdPとのWorkload Identity連携のアーキテクチャを解説します

OIDC対応の外部IdPとのWorkload Identity連携のアーキテクチャについて説明します。

#Google Cloud (GCP)

#OIDC

村田一紘

2024.01.22

Workload Identity連携とは

Workload Identity連携(Workload Identity Federation)は、Google Cloud の外部で実行されているワークロードに対し、外部IdPとID連携して Google Cloud リソースへのアクセス権を動的に付与できるサービスです。

外部ワークロードはサービスアカウントキーを使用して Google Cloud リソースにアクセスすることもできますが、堅牢な管理が必要なシークレット情報であるため漏洩時の大きなリスクとなります。そのため、サービスアカウントキーの利用は現在 Google Cloud の非推奨となっており、Workload Identity連携を利用することが推奨されています。

ID連携が可能な外部IdPは、AWS や OpenID Connect(OIDC)をサポートするIdP(Microsoft Azure、Terraform Cloud、GitHub Actionsなど)が含まれます。本ブログではOIDC対応の外部IdPとのWokload Identity連携についてのアーキテクチャを解説したいと思います。なお、特定のIdPとの連携設定については記載しません。詳細設定については弊社ブログに AWS や GitHub Actions で Workload Identity連携を構成する方法について記事がありますので参考にしてみてください。

また、その他の詳細は以下公式ドキュメントをご参照ください。

Workload Identity連携の解説

構成イメージ

OIDC対応のIdPとの Workload Identity連携の構成イメージを以下に示します。

コンポーネントの解説

各コンポーネントについて解説します。

Workload：Google Cloud のリソースにアクセスするワークロードを指します。
IdP：OIDC対応の外部 Identity Provider であり、Workloadにアクセスするユーザを認証します。
※Terraform Cloud や GitHub Actions など Workload と IdP が同一プラットフォームに存在するケースもあります。
Workload Identity Pool：連携先外部IdPのプロバイダ情報、外部IdPから連携されたOIDCトークンをGoogle STSトークンに交換するための設定や認証のための条件を設定します。
Google STS：Workload Identity Poolと連携して外部IdPから連携されたOIDCトークンを検証し、Google STSトークンに交換します。また、WorkloadからGoogle STSトークンを受領し、Google Cloud APIsにアクセス可能なOAuth 2.0アクセストークンをWorkloadに渡します。
Service Account：特定の Google Cloud Resources を操作するために用意するサービスアカウントです。Google STSが提供するOAuth 2.0アクセストークンは、Service Accountの権限を借用し、WorkloadからGoogle Cloud APIs経由でGoogle Cloud Resourcesを操作できるようにします。
Google Cloud APIs：Google Cloud Resources にアクセスするためのAPIです。
Google Cloud Resources：Workloadが操作するGoogle Cloudのリソースです。

①OIDCトークンの取得

Workload は IdP から JWT(JSON Web Token)データ形式のOIDCトークン(IDトークン)を受領します。OIDCトークンのペイロード内に定義されるClaimaudには以下を構成する必要があります。
※Claim：キーと値で表現するさまざまな情報。認証されたユーザの情報や、有効期限、認証方法などがJSON形式で記載される。
※OIDCトークンのペイロード：JWTデータ形式は「ヘッダ」「ペイロード」「電子署名」を.(ドット)繋ぎで表現します。ペイロードにはClaimが記載されています。

https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

項目	説明
PROJECT_NUMBER	アクセス対象のGoogle Cloudプロジェクトを指定
POOL_ID	Workload Identity PoolのIDを指定
PROVIDER_ID	連携先外部IdPのプロバイダ情報に設定されるIDを指定

なお、Terraform Cloudなどのプロバイダはaudの構成方法を公式ドキュメントに記載していますので参考にしてください。

また、上記audの構成とする場合、Workload Identity Poolでは以下のようにデフォルトの設定としておきます。

②OIDCトークンの提供

Workloadが①で取得したOIDCトークンをGoogle STSに提供します。

③OIDCトークンの署名検証

Google STSは、外部IdPのJWKS(JSON Web Key Set)エンドポイントにアクセスして公開鍵を取得し、JWTに付与されている電子署名を検証します。この検証により、OIDCトークンが外部IdPによって正しく発行され、途中で改ざんされていないことを確認します。

Google STSは、IdPの基本OIDCメタデータhttps://[IdP]/.well-known/openid-configurationのjwks_uriからJWKSエンドポイントのURLを取得してアクセスします。
上記[IdP]の設定は以下のように [発行元(URL)] に設定します。(以下はTerraform CloudがIdPの場合)

④OIDCトークンの属性マッピングと属性条件の検証

Google STSは、Workload Identity Poolで設定した「属性マッピング」により、OIDCトークンのClaim → Google STSトークンの属性にマッピングしてGoogle STSトークンを生成します。
Google STSトークンの属性には以下があります。

項目	説明
google.subject	ユーザの一意の識別子であり、必須の属性
google.groups	ユーザが所属するグループ
attribute.NAME	カスタムの属性

Claimのユーザ情報subをgoogle.subjectにマッピングするには以下の [Google2 / OIDC2] のようにします。
※Claimを指定するにはassersion.Claim名と指定します。

また、その他の特定のユーザやワークロードからのアクセスを認証の条件としたり、Google Cloudのリソース内で利用可能な属性とするために、Claimを様々な属性にマッピングできます。上記はTerraform Cloudと連携する際の設定例ですが、上記の [Google1 / OIDC1] や [Google3 / OIDC3] のようにマッピングの設定が可能です。

なお、Terraform CloudなどのプロバイダはOIDCトークンに定義するClaimを公開していますのでご参照ください。

また、OIDCトークンのClaimを利用して、Google STSトークンをWorkloadに渡すための条件を指定することもできます。認証の条件として特定のユーザやWorkloadを指定する場合などに利用します。以下はTerraform Cloudの特定の「Workspace」と呼ばれるスペースからのアクセスのみを条件とする設定例です。

⑤Google STSトークンと交換

Google STSは、④OIDCトークンの属性マッピングと属性条件の検証を行い、属性条件がtrueとなった場合、Google STSトークンをWorkloadに提供します。

⑥Google STSトークンを使用してService Accountの権限を借用したOAuth 2.0アクセストークンを受領

WorkloadはGoogle STSトークンを使用して、Google STSから有効期限の短いOAuth 2.0アクセストークンを受領します。このOAuth2.0 アクセストークンは、Workload Identity Pool に紐づけた Service Account の権限を借用しており、Service Account に設定したIAMロールに基づいてGoogle Cloud APIsにアクセスすることができます。このトークンの有効期限はデフォルトで60分です。

また、マッピングした属性を利用して、Service Account にアクセス可能なユーザやWorkloadの条件を指定することもできます。
以下、Service Accountの設定例です。