Workload Identity 連携

このドキュメントでは、Workload Identity 連携の概要について説明します。Workload Identity 連携を使用すると、サービス アカウント キーの代わりにフェデレーション ID を使用して、オンプレミスまたはマルチクラウドのワークロードに Google Cloud リソースへのアクセス権を付与できます。

Workload Identity 連携は、アマゾン ウェブ サービス（AWS）と Azure で実行されるワークロード、オンプレミスの Active Directory、GitHub や GitLab などのデプロイ サービス、OpenID Connect（OIDC）または Security Assertion Markup Language（SAML）V2.0 をサポートする任意の ID プロバイダ（IdP）で使用できます。

Workload Identity 連携を使用する理由

Google Cloud の外部で実行されているアプリケーションは、サービス アカウント キーを使用して Google Cloud リソースにアクセスできます。ただし、サービス アカウント キーは強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。Workload Identity 連携により、サービス アカウント キーに関連するメンテナンスとセキュリティの負担が軽減されます。

Workload Identity 連携を使用すると、Identity and Access Management（IAM）を使用して、外部 ID に IAM ロールを付与し、Google Cloud リソースへの直接アクセスを許可できます。サービス アカウントの権限借用によってアクセス権を付与することもできます。

Workload Identity プール

Workload Identity プールは、外部 ID を管理できるエンティティです。

一般に、開発環境、ステージング環境、本番環境など、Google Cloud リソースにアクセスする必要がある Google Cloud 以外の環境ごとに、新しいプールを作成することをおすすめします。

Workload Identity プールのプロバイダ

Workload Identity プールのプロバイダは、Google Cloud と IdP の間の関係を記述するエンティティです。これには次のものが含まれます。

  • AWS
  • Microsoft Entra ID
  • GitHub
  • GitLab
  • Kubernetes クラスタ
  • Okta
  • オンプレミスの Active Directory フェデレーション サービス（AD FS）
  • Terraform

Workload Identity 連携は、OAuth 2.0 トークン交換の仕様に準拠しています。IdP からセキュリティ トークン サービスに認証情報を提供します。このサービスは、認証情報の ID を検証し、連携トークンを返します。

ローカル JWK を使用する OIDC プロバイダ

パブリック OIDC エンドポイントのないワークロードを連携するには、OIDC JSON Web Key Set（JWKS）をプールに直接アップロードします。これは、Terraform または GitHub Enterprise を独自の環境でホストしている場合や、公開 URL を公開できない規制要件がある場合によく使用されます。詳細については、OIDC JWK を管理する（省略可）をご覧ください。

属性のマッピング

外部 IdP によって発行されたトークンには 1 つ以上の属性が含まれています。一部の IdP では、これらの属性をクレームと呼んでいます。

また、Google Security Token Service トークンには次の表に示す 1 つ以上の属性が含まれます。

属性 説明
google.subject 必須。ユーザーの固有識別子。この属性は、IAM principal:// ロール バインディングで使用され、Cloud Logging のログに表示されます。127 文字以内の一意の値にする必要があります。
google.groups 省略可。ID が属するグループのセット。この属性は、IAM の principalSet:// ロール バインディングでグループのすべてのメンバーにアクセス権を付与する場合に使用されます。
attribute.NAME 省略可。最大で 50 個までのカスタム属性を定義できます。これらの属性を IAM principalSet:// ロール バインディングで使用して、特定の属性を持つすべての ID にアクセス権を付与できます。

属性マッピングでは、外部トークンから Google Security Token Service トークン属性の値を派生させる方法を定義します。Google Security Token Service トークン属性ごとに、次の形式で属性マッピングを定義できます。

TARGET_ATTRIBUTE=SOURCE_EXPRESSION

次のように置き換えます。

  • TARGET_ATTRIBUTE は Google Security Token Service トークンの属性です。
  • SOURCE_EXPRESSION は、外部 IdP によって発行されたトークンから 1 つ以上の属性を変換する Common Expression Language（CEL）の式です。

次のリストは、属性マッピングの例を示しています。

  • アサーション属性 sub を google.subject に割り当てます。

    google.subject=assertion.sub

  • 複数のアサーション属性を連結します。

    google.subject="myprovider::" + assertion.aud + "::" + assertion.sub

  • GUID 値のアサーション属性 workload_id を名前にマッピングし、結果を attribute.my_display_name という名前のカスタム属性に割り当てます。

    attribute.my_display_name={
  "8bb39bdb-1cc5-4447-b7db-a19e920eb111": "Workload1",
  "55d36609-9bcf-48e0-a366-a3cf19027d2a": "Workload2"
}[assertion.workload_id]

  • CEL の論理演算子と関数を使用して、ID の Amazon リソース名（ARN）に応じて、attribute.environment という名前のカスタム属性を prod または test に設定します。

    attribute.environment=assertion.arn.contains(":instance-profile/Production") ? "prod" : "test"

  • extract 関数を使用して、想定されたロールの名前カスタム属性 aws_role に設定します。想定されたロールがない場合は、ID の ARN が設定されます。

    attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn

  • split 関数は、指定された区切り値で文字列を分割します。たとえば、メールアドレスの値を @ で分割し、最初の文字列を使用して属性 username を抽出するには、次の属性マッピングを使用します。

    attribute.username=assertion.email.split("@")[0]

  • join 関数は、指定された区切り文字の値に基づいて文字列のリストを結合します。たとえば、区切り文字として . を使用して文字列のリストを連結し、カスタム属性 department に値を挿入するには、次の属性マッピングを使用します。

    attribute.department=assertion.department.join(".")

AWS の場合は、Google はデフォルトのマッピングを指定します。このマッピングは、最も一般的なシナリオに対応しています。カスタム マッピングを指定することもできます。

OIDC プロバイダの場合は、カスタム マッピングを指定します。マッピングを作成するには、認証情報の属性のリストに関するプロバイダのドキュメントを確認してください。

詳細については、API ドキュメントで attributeMapping フィールドの説明をご覧ください。

属性条件

属性条件は、アサーション属性とターゲット属性をチェックする CEL 式です。特定の認証情報の属性条件が true と評価されると、認証情報が受け入れられます。それ以外の場合、認証情報は拒否されます。

属性条件により、Workload Identity プールを使用して認証できる ID を制限できます。

属性条件は、次のようなシナリオで役立ちます。

  • ワークロードが一般に公開されていて利用可能な IdP を使用している場合は、選択した ID のみが Workload Identity プールにアクセスできるようアクセスを制限できます。

  • 複数のクラウド プラットフォームで IdP を使用する場合、別のプラットフォームで使用する予定の認証情報が Google Cloud で使用されないようにできます（逆も同様）。これにより、混乱した使節の問題を回避できます。

Workload Identity プール プロバイダの条件では、assertion キーワードを使用できます。これは、IdP によって発行された認証情報を表すマップを参照します。マップの値には、ドット表記を使用してアクセスできます。たとえば、AWS 認証情報には arn 値が含まれ、assertion.arn としてアクセスできます。さらに、属性条件にはプロバイダの属性マッピングで定義されている任意の属性を使用できます。

次の例では、特定の AWS ロールを持つ ID からのリクエストのみを許可しています。

attribute.aws_role == "ROLE_MAPPING"

詳細については、API ドキュメントで attributeCondition フィールドの説明をご覧ください。

アクセス管理

トークン交換フローは連携アクセス トークンを返します。この連携アクセス トークンを使用すると、Google Cloud リソースのプリンシパル ID の代わりにワークロード アクセスを付与し、有効期間の短い OAuth 2.0 アクセス トークンを取得できます。

このアクセス トークンを使用して IAM アクセスを提供できます。

Workload Identity 連携を使用して、Google Cloud リソースに直接アクセスできるようにすることをおすすめします。ほとんどの Google Cloud APIs は Workload Identity 連携をサポートしていますが、一部の API には制限があります。または、サービス アカウントの権限借用を使用することもできます。

有効期間の短いアクセス トークンを使用すると、リソースまたはサービス アカウントがアクセスできる Google Cloud APIs を呼び出すことができます。

リソースへの直接アクセス

リソースへの直接アクセスを使用すると、リソース固有のロールを介して、外部 ID に Google Cloud リソースへの直接アクセスを許可できます。

代替手段: サービス アカウントの権限借用

リソースへの直接アクセスの代わりに、サービス アカウントの権限借用を使用できます。

サービス アカウントに Workload Identity ユーザー（roles/iam.workloadIdentityUser）ロールを付与する必要があります。

プリンシパル スコープとセキュリティ

プリンシパルまたはそのサブセットにアクセス権を付与するには、プリンシパル タイプを使用します。

プリンシパルのタイプ

次の表に、プリンシパルを個人と ID のグループとして定義する方法を示します。

ID ID の形式
単一の ID principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
グループ内のすべての ID principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP_ID
特定の属性値を持つすべての ID principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE

次のステップ