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

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

なお、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トークンの属性には以下があります。

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の設定例です。

⑦OAuth 2.0アクセストークンを利用し、Google Cloud APIs経由でGoogle Cloudのリソースにアクセス

Workloadは⑥で受領した、Service Acountの権限を借用した有効期限の短いOAuth 2.0アクセストークンを利用して、Google Cloud APIs 経由で Google Cloud Resources を操作します。

さいごに

OIDC対応の外部IdPとのWorkload Identity連携のアーキテクチャについて説明しました。今後は特定のプロバイダとの具体的な連携設定についてもご紹介していければと考えています。