Workforce Identity の連携

このドキュメントでは、Workforce Identity 連携の主なコンセプトについて説明します。

Workforce Identity 連携とは

Workforce Identity 連携では、外部 ID プロバイダ（IdP）を使用して、ワークフォース（従業員、パートナー、請負業者などのユーザー グループ）を IAM を使用して認証および認可し、ユーザーが Google Cloud サービスにアクセスできるようにします。Workforce Identity 連携では、Cloud Identity の Google Cloud Directory Sync（GCDS）とは異なり、既存の IdP から Google Cloud ID にユーザー ID を同期する必要はありません。Workforce Identity 連携は、Google Cloud の ID 機能を拡張して、同期のない属性ベースのシングル サインオンをサポートします。

注: 一部の IdP では、属性はクレームまたはアサーションとも呼ばれます。

ユーザー認証後、IdP から受信した情報を使用して Google Cloud リソースへのアクセス範囲を決定します。

Workforce Identity 連携は、OpenID Connect（OIDC）や SAML 2.0 をサポートする任意の IdP（Microsoft Entra ID、Active Directory Federation Services（AD FS）、Okta など）で使用できます。

注: IdP を使用して、Workforce ユーザーではなくワークロードを認証することもできます。詳細については、Workload Identity 連携をご覧ください。

Workforce Identity プール

Workforce Identity プールを使用すると、Workforce ID のグループと、Google Cloud リソースへのアクセスを管理できます。

プールを使用すると、次のことができます。

• グループ ユーザー ID。例: employees、partners
• プール全体またはその一部に対する IAM アクセス権を付与する。
• ID を 1 つ以上の IdP から連携する。
• 同様のアクセス権限を必要とするユーザー グループにポリシーを定義する。
• IdP 固有の構成情報（属性のマッピングや属性の条件など）を指定する。
• サードパーティ ID の Google Cloud CLI と API アクセスを有効にする。
• プール内のユーザーによるアクセスをプール ID とともに Cloud Audit Logs に記録する。

複数のプールを作成できます。このようなアプローチの例については、複数の Workforce ID プールの例をご覧ください。

プールは Google Cloud 組織レベルで構成されます。このため、プールを表示する適切な IAM 権限があれば、組織内のすべてのプロジェクトとフォルダで使用できます。組織に対して Workforce Identity 連携を初めて設定するときに、プールの名前を指定します。IAM の許可ポリシーでは、その名前でプールを参照します。そのため、プールに含まれる ID が明確にわかる名前にすることをおすすめします。

Workforce Identity プール プロバイダ

Workforce Identity プール プロバイダは、Google Cloud 組織と IdP との関係を記述するエンティティです。

Workforce Identity 連携は、OAuth 2.0 Token Exchange 仕様（RFC 8693）に準拠します。外部 ID プロバイダの認証情報をセキュリティ トークン サービスに提供します。セキュリティ トークン サービスにより認証情報の ID が確認されると、代わりに有効期間が短い Google Cloud アクセス トークンが返されます。

OIDC フロータイプ

OIDC プロバイダの場合、Workforce Identity 連携で認可コードフローと暗黙的フローの両方がサポートされています。トークンは、ユーザーが認証された後、IdP から Google Cloud に直接、別の安全なバックエンド トランザクションで返されるため、認可コードフローが最も安全と考えられます。その結果、コードフロー トランザクションは任意のサイズのトークンを取得できるため、属性マッピングや属性条件に使用するクレームを増やすことができます。暗黙的フローでは、ID トークンが IdP からブラウザに返されます。トークンには、ブラウザの URL サイズの上限が適用されます。

Google Cloud Workforce Identity 連携コンソール

Workforce Identity プール内のユーザーは、Google Cloud Workforce Identity 連携コンソールにアクセスできます。このコンソールはコンソール（連携）ともいわれます。こうしたユーザーはこのコンソールで、Workforce Identity 連携をサポートする Google Cloud プロダクトに UI アクセスできます。

属性のマッピング

IdP によって属性（一部の IdP では「クレーム」）が提供されます。属性にはユーザーに関する情報が含まれます。Google Cloud で使用できるように、これらの属性を Common Expression Language（CEL）を使用してマッピングできます。

このセクションでは、Google Cloud が提供する必須の属性と省略可能な属性のセットについて説明します。

IdP でカスタム属性を定義して、IAM 許可ポリシーなど特定の Google Cloud プロダクトで使用することもできます。

属性マッピングの最大サイズは 4 KB です。

属性は次のとおりです。

• google.subject（必須）: 認証ユーザーの固有識別子。Cloud Audit Logs のログには、このフィールドの内容がプリンシパルとして記録されるため、多くの場合、これは JWT のサブジェクト アサーションになります。このフィールドを使用して、承認判断に必要な IAM を構成できます。IdP のユーザー ディレクトリの値を変更すると、ユーザーがアクセスできなくなるため、変更可能な値を使用しないことをおすすめします。

  最大長は 127 バイトです。

• google.groups（省略可）: 認証するユーザーが属しているグループのコレクション。文字列配列を生成する CEL のサブセットを使用して、論理式を構成できます。このフィールドを使用して、承認判断に必要な IAM を構成することもできます。google.groups の制限事項は次のとおりです。

  • グループ名は 100 文字以下に制限することをおすすめします。

  • 1 つのユーザーが 100 を超えるグループに関連付けられている場合は、少数のグループを定義して、ユーザーと Google Cloud を連携させるアサーションにのみ、これらのグループを含めます。1 人のユーザーが 100 を超えるグループに属している場合、認証は失敗します。

  • この属性を使用して IAM でアクセス権を付与すると、マッピングされたグループ内のすべてのメンバーにアクセス権が付与されます。したがって、組織内の承認済みユーザーのみが、マッピングされたグループのメンバーを変更できるようにすることをおすすめします。

• google.display_name（省略可）: Google Cloud コンソールでログイン ユーザーの名前の設定に使用する属性。この属性は、IAM の許可ポリシーまたは属性条件では使用できません。

  最大長は 100 バイトです。

• google.profile_photo（省略可）: ユーザーのサムネイル写真の URL。写真を 400x400 ピクセルにすることをおすすめします。この属性を設定すると、その画像が Google Cloud コンソールにユーザーのプロフィール写真として表示されます。この値が設定されていない場合、または値を取得できない場合は、代わりに汎用のユーザー アイコンが表示されます。この属性は、IAM 許可ポリシーまたは属性条件では使用できません。

• google.posix_username（省略可）: 以下に使用される、POSIX 準拠の一意のユーザー名文字列。

  • ブラウザでの SSH。

  • Workforce Identity 連携の OS Login（プレビュー）。

  この属性は、IAM の許可ポリシーまたは属性条件では使用できません。最大 32 文字までです。

• attribute.KEY（省略可）: ユーザー定義の IdP トークンに含まれる属性。これらのカスタム属性を使用して、IAM 許可ポリシーで認証戦略を定義できます。たとえば、ユーザーのコストセンター（attribute.costcenter = "1234"）などの属性を定義できます。この属性を IAM Conditions で使用して、そのコストセンターのユーザーにのみアクセス権を付与できます。

  最大 50 個のカスタム属性のマッピング ルールを構成できます。このようなルールの最大サイズは 2,048 文字です。

  ここでマッピングできる属性に制限はありませんが、値が一定の属性を選択することを強くおすすめします。たとえば、attribute.job_description のような属性は、さまざまな理由（可読性の向上など）で変更される可能性があります。代わりに attribute.role を使用することを検討してください。後者の変更は、割り当てられた責任が変更され、ユーザーに付与されているアクセス権が変更されることを意味します。

属性値は、標準の CEL 関数を使用して変換できます。次のカスタム関数を使用することもできます。

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

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

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

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

属性条件

属性条件は、Google Cloud が受け入れる ID 属性に制約を設定できるオプションの CEL 式です。

警告: マルチテナント IdP に 1 つの発行元 URI がある場合は、属性条件を使用して、正しいテナントにアクセスが制限されるようにする必要があります。詳細については、GitHub または他のマルチテナント ID プロバイダと連携する場合に属性条件を使用するをご覧ください。

属性条件を使用するメリットは次のとおりです。

• 属性条件を使用して、外部 ID のサブセットのみが Google Cloud プロジェクトに対して認証されるようにできます。たとえば、特にパブリック IdP を使用している場合、特定のチーム内の ID にのみログインを許可できます。また、会計チームにログインを許可するが、エンジニアリング チームにはログインを許可しないこともできます。
• 属性条件を使用すると、別のプラットフォームで使用する認証情報が Google Cloud で使用されないようにできます（逆も同様）。これにより、混乱した使節の問題を回避できます。

GitHub または他のマルチテナント ID プロバイダと連携する場合に属性条件を使用する

Workforce Identity 連携は、ユーザー アカウントのディレクトリを維持しません。代わりにクレームベースの ID を実装します。そのため、同じ ID プロバイダ（IdP）によって 2 つのトークンが発行され、それらのクレームが同じ google.subject 値にマッピングされている場合、2 つのトークンは同じユーザーを表しているとみなされます。トークンを発行した IdP を調べるために、Workforce Identity 連携はトークンの発行元 URL を検証します。

GitHub や Terraform Cloud などのマルチテナント ID プロバイダは、すべてのテナントで単一の発行元 URL を使用します。これらのプロバイダでは、発行元 URL は特定の GitHub または Terraform Cloud 組織ではなく、GitHub または Terraform Cloud 全体を表します。

これらの ID プロバイダを使用する場合は、Workforce Identity 連携でトークンの発行元 URL をチェックし、トークンの発行元 URL が信頼できるソースから取得され、そのクレームが信頼できることを確認するだけでは不十分です。マルチテナント IdP に 1 つの発行元 URL がある場合は、属性条件を使用して、正しいテナントにアクセスが制限されるようにすることをおすすめします。

IAM ポリシーで Workforce プールユーザーを表す

次の表に、単一ユーザー、ユーザー グループ、特定のクレームを持つユーザー、または Workforce プールのすべてのユーザーにロールを付与する際に使用するプリンシパル ID を示します。

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

JSON Web キー

Workforce プール プロバイダは、/.well-known/openid-configuration ドキュメントの jwks_uri フィールドの IdP から提供される JSON Web Key（JWK）にアクセスできます。この情報が OIDC プロバイダから提供されない場合、または発行者が一般公開されていない場合は、OIDC プロバイダを作成または更新するときに JWK を手動でアップロードできます。

組織間のアクセスを制限する

Workforce Identity プールのプリンシパルは、所属する組織外のリソースに直接アクセスすることはできません。ただし、組織内でサービス アカウントの権限借用を行う権限がプリンシパルに付与されている場合、サービス アカウントが均等に制限されないため、この制約は回避できます。

Workforce プールのユーザー プロジェクト

ほとんどの Google Cloud APIs では、API リクエストがアクセスするリソースを含むプロジェクトに対して課金と割り当てが適用されます。これらの API はリソースベースの API と呼ばれます。一部の Google Cloud APIs では、クライアントに関連付けられたプロジェクトに対して課金を行います。これらはクライアント ベースの API と呼ばれます。課金と割り当てのために使用されるプロジェクトは、割り当てプロジェクトと呼ばれます。

Workforce Identity 連携構成ファイルを作成するときに、Workforce プールのユーザー プロジェクトを指定します。このプロジェクトは、アプリケーションが呼び出す Google API に対してアプリケーションの識別を行うために使用されます。Workforce プールのユーザー プロジェクトは、gcloud CLI を使用して API リクエストを開始しない限り、クライアントベースの API のデフォルトの割り当てプロジェクトとしても使用されます。指定するプロジェクトに対する serviceusage.services.use 権限が必要です。この権限は、Service Usage ユーザー（roles/serviceusage.serviceUsageConsumer）のロールに含まれています。

割り当てプロジェクト、リソースベースの API、クライアントベースの API の詳細については、割り当てプロジェクトの概要をご覧ください。

例: 複数の Workforce Identity プール

このセクションでは、複数のプールの一般的な使用例を示します。

従業員用とパートナー用に別のプールを作成できます。多国籍企業の場合、組織内のさまざまな部門に個別のプールを作成できます。プールにより分散管理が可能になります。分散管理では、さまざまなグループが特定のプールを個別に管理できます。この場合、プール内の ID にのみロールが付与されます。

たとえば、Enterprise Example Organization という名前の企業が、Partner Example Organization Inc. という別の企業と契約を結び、Google Kubernetes Engine（GKE）DevOps サービスを提供しているとします。Partner Example Organization の従業員がサービスを提供するには、従業員が Enterprise Example Organization の組織内の Google Kubernetes Engine（GKE）や他の Google Cloud リソースにアクセスできる必要があります。Enterprise Example Organization には、すでに enterprise-example-organization-employees という Workforce Identity プールがあります。

Partner Example Organization が Enterprise Example Organization のリソースへのアクセスを管理できるようにするため、Enterprise Example Organization では、Partner Example Organization の Workforce ユーザーが使用できる Workforce プールを別途作成し、Partner Example Organization が管理できるようにします。Enterprise Example Organization は、Partner Example Organization の管理者に Workforce プールを提供します。Partner Example Organization の管理者は、自分の IdP を使用して、従業員にアクセス権を付与します。

これを行うために、Enterprise Example Organization の管理者は次のタスクを行います。

1. Enterprise Example Organization の IdP 内に、[e-mail] などの ID を Partner Example Organization の管理者用に作成します。これは、enterprise-example-organization-employees というプールですでに構成されています。

2. example-organization-partner という名前の新しい Workforce プールを作成します。

3. example-organization-partner プールに次の許可ポリシーを作成します。

   {
     "bindings": [
       {
         "role": "roles/iam.workforcePoolEditor",
         "members": [
           "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/[e-mail]"
         ]
       }
     ]
   }
   

4. Enterprise Example Organization の組織でアクセスする必要があるリソースに example-organization-partner プールのロールを付与します。

Partner Example Organization の管理者は、IdP に接続するように example-organization-partner プールを構成できます。Partner Example Organization の従業員は、Partner Example Organzation の IdP 認証情報を使用してログインできます。ログイン後、Partner Example Organization の従業員は、Enterprise Example Organization で定義されたポリシーによって制限されている Google Cloud リソースにアクセスできます。

アクセス管理が簡単

大企業では、IT 管理者がベスト プラクティスのアクセス制御モデルの一部としてセキュリティ グループを作成することがよくあります。セキュリティ グループは内部リソースへのアクセスを制御します。さらに、従業員用に追加のグループを作成し、パートナー用に別のグループを作成して、このアクセス制御モデルをクラウド リソースに拡張していることも少なくありません。その結果、ネストの深いグループが急増し、管理が困難になる場合があります。

組織によっては、ユーザー ディレクトリ階層をある程度平坦にするために、作成できるグループの数を制限するポリシーを設定している場合もあります。IAM ポリシーの構成ミスを防止し、グループの拡張を制限する効果的な解決策は、複数のプールを使用して、異なる組織部門やビジネス ユニット、パートナー組織のユーザーをより幅広く分離することです。これにより、これらのプールとプールに含まれるグループを参照して IAM ポリシーを定義できます（IAM の構成手順の例をご覧ください）。

VPC Service Controls の制限事項

Workforce Identity 連携、Workforce プール構成 API、セキュリティ トークン サービス API は、VPC Service Controls をサポートしていません。ただし、Workforce プールのユーザーがアクセスできる Google Cloud プロダクトは、VPC Service Controls をサポートしています。詳細については、VPC Service Controls のサポートされているプロダクトと制限事項のページをご覧ください。

Workforce Identity 連携と重要な連絡先

組織または Google Cloud プロダクトの変更に関する重要な情報を受け取るには、Workforce Identity 連携を使用するときに重要な連絡先を指定する必要があります。Cloud Identity ユーザーへの連絡には Cloud Identity メールアドレスを使用できますが、Workforce Identity 連携ユーザーの連絡には重要な連絡先を使用します。

Google Cloud コンソールで Workforce Identity プールを作成または管理するときに、法的事項と停止の通知先となる重要な連絡先を構成するように求めるバナーが表示されます。個別の連絡先がない場合は、[すべて] カテゴリで連絡先を定義できます。連絡先を指定すると、バナーが削除されます。

次のステップ

• Workforce Identity 連携を設定する方法については、Workforce Identity 連携の構成をご覧ください。IdP 固有の手順については、以下をご覧ください。
  • Microsoft Entra ID との Workforce Identity 連携を構成してユーザー ログインを行う
  • Okta との Workforce Identity 連携を構成してユーザー ログインを行う
• Workforce Identity 連携の有効期間が短いトークンを取得する
• Workforce プール プロバイダを管理する
• Workforce Identity 連携ユーザーとそのデータを削除する
• Workforce Identity 連携の監査ログを表示する
• Workforce Identity 連携をサポートするプロダクトを表示する
• コンソール（連携）へのユーザー アクセスを設定する