Active Directory との Workload Identity 連携を構成する

このガイドでは、Workload Identity 連携を使用して、ワークロードが Active Directory 認証情報を使用して Google Cloud で認証できるようにする方法について説明します。

Windows Server ワークロードを Active Directory 環境で実行している場合、これらのワークロードは Active Directory の認証情報にアクセスできる可能性があります。次に例を示します。

Windows サービスがドメインユーザーとしてログインするように構成されている場合があります。
グループマネージドサービスアカウント（gMSA）として実行されるように IIS アプリケーションを構成されている可能性もあります。

Workload Identity 連携を Active Directory フェデレーションサービス（AD FS）と組み合わせて使用すると、これらのワークロードは Active Directory Kerberos 認証情報を有効期間の短い Google Cloud 認証情報と交換できるようになります。ワークロードは、これらの有効期間が短い認証情報を使用して Google Cloud APIs にアクセスできます。

有効期間が短い Google Cloud の認証情報と Active Directory の認証情報を交換するには、2 つのトークン交換を統合します。

ワークロードは、OpenID Connect（OIDC）、SAML-POST、または WS-Trust を使用して、AD FS からの OIDC トークンまたは SAML アサーションをリクエストします。AD FS への認証では、ワークロードは統合 Windows 認証（IWA）と既存の Active Directory 認証情報を使用します。
ワークロードは Workload Identity 連携を使用して、OIDC トークンまたは SAML アサーションを Security Token Service トークンと交換します。必要に応じて、Google Cloud サービスアカウントの権限を借用することもできます。

このドキュメントでは、Workload Authenticator for Windows を使用して、アプリケーションを変更せずにこのプロセスを自動化する方法について説明します。

AD FS を準備する

この手順は 1 回だけ行います。

プロトコルを選択する

AD FS を準備する方法は、使用するプロトコルによって異なります。

SAML: ワークロードが SAML または WS-Trust を使用して SAML アサーションを取得できるようにします。

SAML または WS-Trust を使用するには、AD FS で証明書利用者を作成し、この証明書利用者に対して発行されたアサーションを信頼するように Workload Identity プールを構成します。

ワークロードは、SAML POST バインディングまたは WS-Trust のいずれかを利用して、AD FS で Active Directory ユーザーの認証を行うことができます。AD FS は、ワークロードの Active Directory ユーザーに関する情報やグループメンバーシップなどの追加情報を含む SAML アサーションを発行します。

SAML または WS-Trust を使用するには、AD FS 3.0、Windows Server 2016 用の AD FS、またはそれより新しいバージョンの AD FS が必要です。
OIDC: ワークロードで OIDC を使用して OIDC トークンを取得できます。

OIDC を使用するには、AD FS で OIDC クライアント（ネイティブアプリケーション）と OIDC リソース（Web API）を作成します。次に、Workload Identity プールを構成して、Web API 用に発行されたアクセストークンを信頼します。

ワークロードは、Active Directory ユーザーと OAuth client_credentials の付与を使用して AD FS に対する認証を行うことができます。AD FS はアクセストークンを発行しますが、ID トークンは発行しません。

アクセストークンには OIDC クライアントアプリケーションに関する情報が含まれますが、ワークロードの Active Directory ユーザーまたはそのグループメンバーシップに関する情報は含まれません。

アクセストークンには Active Directory ユーザーに関する情報が含まれていません。OIDC を使用する場合は、SAML または WS-Trust を使用するよりも柔軟性が低くなります。

OIDC を使用するには、Windows Server 2016 用の AD FS または新しいバージョンの AD FS が必要です。

ログインの場合、IdP は署名付き認証情報を提供する必要があります。OIDC IdP は JWT を提供し、SAML IdP レスポンスは署名されている必要があります。

IWA の前提条件

このセクションでは、このガイドを使用するために必要な IWA の前提条件について説明します。

AD FS とともに IWA を使用したことがない場合は、次の前提条件を満たしていることを確認してください。

Windows 認証を許可するように AD FS を構成し、適切なサービスプリンシパル名を使用している。
認証のための拡張保護が AD FS デプロイと互換性を持つように構成されている。

ワークロードを登録する

AD FS にワークロードを登録するには、次の操作を行います。

OIDC

ワークロードで OIDC を使用できるようにするには、AD FS で 2 つのアプリケーション登録が必要です。

ネイティブアプリケーションまたはサーバーアプリケーションのタイプのアプリケーション登録。
Google Cloud 上の Workload Identity プールプロバイダに対応する Web API タイプのアプリケーション登録。

クライアントアプリケーションを登録する

ワークロードを表すクライアントアプリケーションを作成します。Google Cloud にアクセスする必要があるワークロードが複数ある場合は、複数のクライアントアプリケーションの作成が必要になることがあります。

AD FS でクライアントアプリケーションを登録するには、次の操作を行います。

AD FS MMC スナップインを開き、[アプリケーショングループ] に移動します。
[アプリケーショングループの追加] をクリックします。
[ようこそ] ページで、次の操作を行います。
1. テキストフィールドにクライアントの名前を入力します。
2. [サーバーアプリケーション] を選択します。
3. [次へ] をクリックします。
[サーバーアプリケーション] ページで、次の操作を行います。
1. [text-field] テキストフィールドに、クライアント識別子（クライアント ID）とリダイレクト URI を入力します。
  
  client_credentials 付与タイプのみを使用する場合、リダイレクト URI は使用されないため、http://localhost/ などの URI を使用できます。
2. [次へ] をクリックします。
[アプリケーションの資格情報の構成] ページで、次の操作を行います。
1. クライアントの認証方法を選択します。IWA を使用するには、[Windows 統合認証] を [有効] に設定します。
2. アプリケーションを実行するドメインユーザーを選択します。
3. [次へ] をクリックします。
[概要] ページで、設定を確認して [次へ] をクリックします。
[閉じる] をクリックしてダイアログを閉じます。

Workload Identity プール用のウェブ API アプリケーションを作成する

Web API タイプの別のアプリケーション登録を作成します。このアプリケーションは Workload Identity プールのプロバイダに対応し、Google Cloud との信頼関係を設定するために使用します。

AD FS でアプリケーションを作成する手順は次のとおりです。

AD FS MMC スナップインを開き、[アプリケーショングループ] に移動します。
[アプリケーショングループの追加] をクリックします。
スタートページで、「Workload Identity Federation (test environment)」などの名前を入力し、[Web API] を選択します。[次へ] をクリックします。
[Web API の構成] ページで、ウェブ API 用の証明書利用者 ID を入力します。

カスタム証明書利用者 ID を定義するのではなく、次の URI を証明書利用者 ID として使用できます。
```
https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID/providers/PROVIDER_ID
```
次のように置き換えます。
- PROJECT_NUMBER: Workload Identity プールの作成に使用する Google Cloud プロジェクトのプロジェクト番号。
- WORKLOAD_POOL_ID: Workload Identity プールを識別する任意の ID。後で Workload Identity プールを作成するときに、この ID を使用する必要があります。
- PROVIDER_ID: Workload Identity プールのプロバイダを識別する任意の ID。後で Workload Identity プールのプロバイダを作成するときに、この ID を使用する必要があります。
この方法で URI をフォーマットすることで、証明書利用者 ID によって Workload Identity プールのプロバイダが一意に識別されます。

証明書利用者 ID は、後で Workload Identity プールプロバイダを構成するときに必要になります。
[次へ] をクリックします。
[アクセス制御ポリシーの適用] ページで、適切なアクセスポリシーを選択し、[次へ] をクリックします。
[アプリケーションのアクセス許可の構成] ページで、前に作成したクライアントアプリケーションを追加します。[次へ] をクリックします。
[概要] ページで、設定を確認して [次へ] をクリックします。
[閉じる] をクリックしてダイアログを閉じます。

SAML または WS-Trust

AD FS で証明書利用者信頼を作成します。

AD FS MMC スナップインを開きます。
[証明書利用者信頼] に移動します。
[証明書利用者信頼の追加] をクリックします。
[証明書利用者信頼の追加] ウィザードの [ようこそ] ページで、次の操作を行います。
1. [要求に対応する] を選択します。
2. [開始] をクリックします。
[データソースの選択] ページで、次の操作を行います。
1. [証明書利用者についてのデータを手動で入力する] を選択します。
2. [次へ] をクリックします。
[表示名の指定] ページで、次の操作を行います。
1. 信頼の名前を入力します。
2. [次へ] をクリックします。
[証明書の構成] ページで、[次へ] をクリックします。Workload Identity 連携は暗号化された SAML をサポートしていますが、ここでは説明しません。詳細については、このガイドの後半の ID プールとプロバイダを作成するの gcloud CLI の手順をご覧ください。
[URL の構成] ページで、次の操作を行います。
SAML
次の設定を使用します。
- [SAML 2.0 WebSSO プロトコルのサポートを有効にする] を「有効」に設定します。
- [証明書利用者 SAML 2.0 SSO サービスの URL] に次の URL を入力します。
```
https://sts.googleapis.com/v1/token
```
WS-Trust
デフォルトの設定をそのまま使用します。
[次へ] をクリックします。
[識別子の構成] ページで、証明書利用者 ID を入力します。

カスタム証明書利用者 ID を定義するのではなく、次の URI を証明書利用者 ID として使用できます。
```
https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID/providers/PROVIDER_ID
```
次のように置き換えます。
- PROJECT_NUMBER: Workload Identity プールの作成に使用する Google Cloud プロジェクトのプロジェクト番号。
- WORKLOAD_POOL_ID: Workload Identity プールを識別する任意の ID。後で Workload Identity プールを作成するときに、この ID を使用する必要があります。
- PROVIDER_ID: Workload Identity プールのプロバイダを識別する任意の ID。後で Workload Identity プールのプロバイダを作成するときに、この ID を使用する必要があります。
この方法で URI をフォーマットすることで、証明書利用者 ID によって Workload Identity プールのプロバイダが一意に識別されます。

証明書利用者 ID は、後で Workload Identity プールプロバイダを構成するときに必要になります。
[次へ] をクリックします。
[アクセス制御ポリシーの選択] ページで、適切なアクセス制御ポリシーを選択し、[次へ] をクリックします。
[信頼の追加の準備完了] ページで設定内容を確認して、[次へ] をクリックします。
[終了] ページで [閉じる] をクリックして、ダイアログを閉じます。

Workload Identity 連携との互換性を確保するために、SAML アサーションには、Active Directory ユーザーを一意に識別する要求が 1 つ以上含まれている必要があります。通常は、この目的のため、SAML アサーションの NameID 要素の値に対応する名前 ID 要求を使用します。

SAML アサーションの一連の要求をカスタマイズするには、証明書利用者信頼の要求発行ポリシーを編集する必要があります。要求発行ポリシーを編集する手順は次のとおりです。

証明書利用者信頼のリストで、作成した信頼を選択し、[要求発行ポリシーの編集] をクリックします。
[規則の追加] をクリックします。
[変換要求規則の追加] ウィザードの [ 規則の種類の選択] ページで、次の操作を行います。
1. [入力方向の要求を変換] を選択します。
2. [次へ] をクリックします。
[要求規則の構成] ページで、次の設定を構成します。
- 要求規則名: Name Identifier。
- 入力方向の要求の種類: プライマリ SID または UPN。あるいは、サブジェクトを一意に識別する別の要求を選択します。
- 出力方向の要求の種類: 名前 ID。
- 出力方向の名前 ID の形式: 指定なし。
[すべての要求値をパススルーする] を選択し、[終了] をクリックします。
必要に応じて追加の規則を構成し、SAML アサーションに属性を追加します。
[OK] をクリックして、要求発行ポリシーのダイアログを閉じます。

Workload Identity 連携を構成する

この操作は、連携する Azure AD テナントまたは AWS アカウントごとに 1 回だけ行います。これにより、複数のワークロードや複数の Google Cloud プロジェクトで同じ Workload Identity プールとプロバイダを使用できます。

Workload Identity 連携の構成を開始するには、次の操作を行います。

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Workload Identity プールとプロバイダの管理に専用のプロジェクトを使用する

Make sure that billing is enabled for your Google Cloud project.

Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

Enable the APIs

属性のマッピングと条件を定義する

AWS または Azure ワークロードの環境固有の認証情報には複数の属性が含まれているため、Google Cloud でサブジェクト識別子（google.subject）として使用する属性を決定する必要があります。

必要に応じて、追加の属性をマッピングできます。これにより、リソースへのアクセス権を付与する際にこれらの追加属性を参照できます。

OIDC

属性マッピングでは、AD FS アクセストークンに埋め込まれた要求をソース属性として使用できます。

アプリケーションの認証には、次の属性マッピングを使用できます。

google.subject=assertion.appid

このマッピングにより、google.subject が appid 要求の値に設定されます。この値には AD FS アプリケーションのクライアント ID が含まれます。

SAML または WS-Trust

このガイドですでに説明したとおり、属性マッピングでは、AD FS によって発行されたアサーションに埋め込まれた要求を使用できます。

次のマッピングを使用して、Workload Identity 連携で SAML アサーションの名前 ID 要求を使用してユーザーを一意に識別するようにします。

google.subject=assertion.subject

SAML アサーションに要求を含めるように要求発行ポリシーを構成している場合は、別のマッピングを追加できます。次に例を示します。

google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid']
attribute.userip=['http://schemas.microsoft.com/2014/09/requestcontext/claims/userip'][0]

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

OIDC

属性条件を使用して、有効期間の短い Google Cloud トークンを取得するために Workload Identity 連携を使用できるクライアントを制限できます。

たとえば、次の条件は、アプリケーションが AD FS への認証に IWA を使用する必要があることを定義します。

assertion.authmethod=='http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows'

有効期間が短い Google Cloud の認証情報を取得できるアプリケーションのリストを制御する場合は、属性条件を定義しないでください。代わりに、AD FS でクライアント権限を使用して、許可するアプリケーションを定義します。

SAML または WS-Trust

属性条件を使用して、有効期間の短い Google Cloud トークンを取得するために Workload Identity 連携を使用できる Active Directory ユーザーを制限できます。

たとえば、次の条件は、特定のグループメンバーシップ要求が含まれる SAML アサーションのみを許可します。

"S-1-5-6" in google.groups

Workload Identity のプールとプロバイダを作成する

必要なロール

Workload Identity 連携の構成に必要な権限を取得するには、プロジェクトに対して次の IAM ロールを付与するよう管理者に依頼してください。

Workload Identity プール管理者（roles/iam.workloadIdentityPoolAdmin）
サービスアカウント管理者（roles/iam.serviceAccountAdmin）

ロールの付与の詳細については、アクセスの管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

また、IAM オーナー（roles/owner）の基本ロールには ID 連携を構成する権限も含まれています。本番環境では基本ロールを付与すべきではありません。基本ロールは、開発環境またはテスト環境で付与してください。

コンソール

Google Cloud コンソールで、[新しいワークロードプロバイダとプール] ページに移動します。

[新しいワークロードプロバイダとプール] に移動
[ID プールを作成] に、次のように入力します。
- 名前: プールの名前。この名前はプール ID としても使用されます。プール ID を後で変更することはできません。
- 説明: プールの目的を説明するテキスト。
[続行] をクリックします。
プロバイダを構成します。
OIDC
- プロバイダを選択: OpenID Connect（OIDC）。
- プロバイダ名: プロバイダの名前。この名前はプロバイダ ID としても使用されます。プロバイダ ID は後から変更できません。
- 発行元の URL: https://ADFS_DOMAIN/adfs。ここで、ADFS_DOMAIN は AD FS サーバーまたはファームのパブリックドメイン名です。
SAML
SAML 2.0 互換 IdP から Workload Identity 連携を構成するには、gcloud CLI の手順に沿って操作します。
[続行] をクリックします。
[プロバイダの属性を構成する] で、前に確認した属性マッピングを追加します。
[属性条件] で、前に確認した属性条件を入力します。属性条件がない場合は、空白のままにします。
[保存] をクリックして、Workload Identity のプールとプロバイダを作成します。

gcloud

新しい Workload Identity プールを作成します。
```
gcloud iam workload-identity-pools create WORKLOAD_POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
次のように置き換えます。
- WORKLOAD_POOL_ID: プールの一意の ID。
- DISPLAY_NAME: プールの名前。
- DESCRIPTION: プールの説明。この説明は、プール ID へのアクセス権を付与するときに表示されます。
Workload Identity プールのプロバイダを追加します。
OIDC
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="WORKLOAD_POOL_ID" \
    --issuer-uri="https://ADFS_DOMAIN/adfs" \
    --allowed-audiences="RELYING_PARTY_ID" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
次のように置き換えます。
- PROVIDER_ID: プロバイダの一意の ID。
- WORKLOAD_POOL_ID: プールの ID。
- ADFS_DOMAIN: AD FS サーバーまたはファームのパブリックドメイン名。
- RELYING_PARTY_ID: AD FS 内の Workload Identity プール用のウェブ API アプリケーションの証明書利用者 ID。このパラメータは、カスタムの証明書利用者 ID を使用する場合にのみ必要です。
- MAPPINGS: 前に確認した属性マッピングのカンマ区切りリスト。
- CONDITIONS: 前に確認した属性条件。属性条件がない場合は、パラメータを削除します。
接頭辞 gcp- は予約されているため、プールやプロバイダ ID では使用できません。
SAML または WS-Trust
```
curl -O https://ADFS_DOMAIN/federationmetadata/2007-06/federationmetadata.xml

gcloud iam workload-identity-pools providers create-saml PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --idp-metadata-path="federationmetadata.xml" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
次のように置き換えます。
- PROVIDER_ID: プロバイダの一意の ID。
- ADFS_DOMAIN: AD FS サーバーまたはサーバーファームのドメイン名。
- WORKLOAD_POOL_ID: プールの ID。
- MAPPINGS: 前に確認した属性マッピングのカンマ区切りリスト。
- CONDITIONS: 省略可。このガイドの前半で作成した属性条件。
接頭辞 gcp- は予約されているため、プールやプロバイダ ID では使用できません。

例:
```
gcloud iam workload-identity-pools providers create-saml example-provider \
    --location="global" \
    --workload-identity-pool="pool-1" \
    --idp-metadata-path="federationmetadata.xml" \
    --attribute-mapping=google.subject=assertion.subject"
```
省略可: IdP から暗号化された SAML アサーションを受け入れる

SAML 2.0 IdP が Workload Identity 連携で受け入れられる暗号化された SAML アサーションを生成できるようにするには、次の操作を行います。
- Workload Identity 連携で次の操作を行います。
- IdP で次の操作を行います。
SAML 暗号化プロバイダの鍵が構成されている場合でも、Workload Identity 連携は平文のアサーションを処理できます。

Workload Identity 連携 SAML アサーション暗号鍵を作成する

このセクションでは、Workload Identity 連携で暗号化された SAML アサーションを受け入れる非対称鍵ペアの作成について説明します。

Google Cloud は秘密鍵を使用して、IdP が発行する SAML アサーションを復号します。SAML 暗号化で使用する非対称鍵ペアを作成するには、次のコマンドを実行します。詳細については、サポートされている SAML 暗号化アルゴリズムをご覧ください。
```
gcloud iam workload-identity-pools providers keys create KEY_ID \
    --workload-identity-pool WORKLOAD_POOL_ID \
    --provider PROVIDER_ID \
    --location global \
    --use encryption \
    --spec KEY_SPECIFICATION
```
次のように置き換えます。
- KEY_ID: 任意の鍵名
- WORKLOAD_POOL_ID: プール ID
- PROVIDER_ID: プロバイダ ID
- KEY_SPECIFICATION: 鍵仕様（rsa-2048、rsa-3072、rsa-4096 のいずれか）。
鍵ペアを作成したら、次のコマンドを実行して、公開鍵を証明書ファイルにダウンロードします。秘密鍵にアクセスできるのは Workload Identity 連携だけです。
```
gcloud iam workload-identity-pools providers keys describe KEY_ID \
    --workload-identity-pool WORKLOAD_POOL_ID \
    --provider PROVIDER_ID \
    --location global \
    --format "value(keyData.key)" \
    > CERTIFICATE_PATH
```
次のように置き換えます。
- KEY_ID: 鍵名
- WORKLOAD_POOL_ID: プール ID
- PROVIDER_ID: プロバイダ ID
- CERTIFICATE_PATH: 証明書を書き込むパス（例: saml-certificate.cer や saml-certificate.pem）
暗号化された SAML アサーションを発行するように SAML 2.0 準拠の IdP を構成する
1. 証明書ファイルを AD FS サーバーに移動します。
2. AD FS サーバーで、[Start] ボタン（または [Win] + X）を右クリックして、[Windows PowerShell (Admin)] をクリックします。
3. PowerShell で次のコマンドを実行して、暗号化を有効にします。
```
        Set-AdfsRelyingPartyTrust `
        -TargetName NAME `
        -SamlResponseSignature MessageAndAssertion `
        -EncryptionCertificate PATH `
        -EncryptClaims $True
    
```
  次のように置き換えます。
  - NAME: 証明書利用者信頼の名前
  - PATH: 証明書ファイルのパス
WS-Trust ユーザー: この機能は SAML を使用している場合にのみ利用できます。

SAML アサーションを暗号化するように IdP を構成したら、IdP によって生成されるアサーションが実際に暗号化されていることを確認することをおすすめします。SAML アサーションの暗号化が構成されている場合でも、Workload Identity 連携は平文のアサーションを処理できます。

Workload Identity 連携暗号鍵を削除する
SAML 暗号鍵を削除するには、次のコマンドを実行します。
```
  gcloud iam workload-identity-pools providers keys delete KEY_ID \
      --workload-identity-pool WORKLOAD_POOL_ID \
      --provider PROVIDER_ID \
      --location global
```
次のように置き換えます。
- KEY_ID: 鍵名
- WORKLOAD_POOL_ID: プール ID
- PROVIDER_ID: プロバイダ ID
サポートされている SAML 暗号化アルゴリズム

Workload Identity 連携は、次の主要なトランスポートアルゴリズムをサポートしています。
Workload Identity 連携は、次のブロック暗号化アルゴリズムをサポートしています。

ワークロードの認証を行う

この手順は、ワークロードごとに 1 回行う必要があります。

外部ワークロードが Google Cloud リソースにアクセスできるようにする

ワークロードに Google Cloud リソースへのアクセス権を付与するには、プリンシパルに直接リソースへのアクセス権を付与することをおすすめします。この場合、プリンシパルは連携ユーザーです。一部の Google Cloud プロダクトには、Google Cloud API の制限事項があります。ワークロードが制限付きの API エンドポイントを呼び出す場合は、サービスアカウントの権限借用を使用できます。この場合、プリンシパルは Google Cloud サービスアカウントであり、ID として機能します。リソースのサービスアカウントにアクセス権を付与します。

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

Google Cloud コンソールまたは gcloud CLI を使用して、リソースへの直接アクセス権を連携 ID に付与できます。

コンソール

Google Cloud コンソールでリソースに IAM ロールを直接付与するには、リソースのページに移動してロールを付与する必要があります。次の例は、Cloud Storage ページに移動し、Cloud Storage バケットでフェデレーション ID にストレージオブジェクト閲覧者（roles/storage.objectViewer）ロールを直接付与する方法を示しています。

Google Cloud コンソールで、Cloud Storage の [バケット] ページに移動します。
[バケット] に移動
バケットのリストで、ロールを付与するバケットの名前をクリックします。
ページ上部にある [権限] タブを選択します。
[ アクセス権を付与] ボタンをクリックします。

[プリンシパルの追加] ダイアログが表示されます。
[新しいプリンシパル] フィールドに、バケットへのアクセスが必要な ID を 1 つ以上入力します。
サブジェクト
```
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
```
次のように置き換えます。
- PROJECT_NUMBER: プロジェクト番号
- POOL_ID: ワークロードプールの ID
- SUBJECT: IdP からマッピングされた個々のサブジェクト（例: administrator@example.com）
グループ
```
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP
```
次のように置き換えます。
- PROJECT_NUMBER: プロジェクト番号
- WORKLOAD_POOL_ID: ワークロードプールの ID
- GROUP: IdP からマッピングされたグループ（例: administrator-group@example.com）。
属性
```
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
```
次のように置き換えます。
- PROJECT_NUMBER: プロジェクト番号
- WORKLOAD_POOL_ID: ワークロードプールの ID
- ATTRIBUTE_NAME: IdP からマッピングされた属性のいずれか
- ATTRIBUTE_VALUE: 属性の値
[ロールを選択] プルダウンメニューからロールを選択します。選択したロールと付与する権限の簡単な説明がパネルに表示されます。
[保存] をクリックします。

gcloud

gcloud CLI を使用してプロジェクトのリソースに IAM ロールを付与するには、次の操作を行います。

リソースが定義されているプロジェクトのプロジェクト番号を取得します。
```
gcloud projects describe $(gcloud config get-value core/project) --format=value$projectNumber$
```
リソースへのアクセス権を付与します。

gcloud CLI を使用して、特定の条件を満たす外部 ID に Workload Identity ユーザーロール（roles/iam.workloadIdentityUser）を付与するには、次のコマンドを実行します。
サブジェクト
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
```
グループ
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
```
属性
```
gcloud storage buckets add-iam-policy-binding BUCKET_ID \
    --role=roles/storage.objectViewer \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
```
次のように置き換えます。
- BUCKET_ID: アクセス権を付与するバケット
- PROJECT_NUMBER: Workload Identity プールを含むプロジェクトのプロジェクト番号
- POOL_ID: Workload Identity プールのプール ID
- SUBJECT: google.subject にマッピングされている属性の想定値
- GROUP: google.groups にマッピングされている属性の想定値
- ATTRIBUTE_NAME: 属性マッピングのカスタム属性の名前
- ATTRIBUTE_VALUE: 属性マッピングのカスタム属性の値
IAM 許可ポリシーをサポートする任意の Google Cloud リソースにロールを付与できます。

注: メンバー ID には、プロジェクト ID ではなくプロジェクト番号を使用する必要があります。

サービスアカウントの権限借用

外部ワークロードのサービスアカウントを作成するには、次の操作を行います。
1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.
  Enable the APIs
2. ワークロードを表すサービスアカウントを作成します。ワークロードごとに専用のサービスアカウントを使用することをおすすめします。
  
  サービスアカウントは、Workload Identity プールと同じプロジェクトにある必要はありません。
3. 外部 ID にアクセスを許可するリソースに対するアクセス権をサービスアカウントに付与します。
4. サービスアカウントに Workload Identity ユーザーロール（roles/iam.workloadIdentityUser）を付与します。
5. ワークロードを表すサービスアカウントを作成します。ワークロードごとに専用のサービスアカウントを使用することをおすすめします。
  
  サービスアカウントは、Workload Identity プールと同じプロジェクトにある必要はありませんが、サービスアカウントを含むプロジェクトを参照する必要があります。
Google Cloud コンソールまたは gcloud CLI を使用してサービスアカウントの権限借用でフェデレーション ID へのアクセス権を付与するには、次の操作を行います。
コンソール
Google Cloud コンソールで、サービスアカウントを使用してフェデレーション ID に IAM ロールを付与する手順は次のとおりです。
1. 次の手順で、権限借用の ID として機能するサービスアカウントを作成します。
  1. Enable the IAM, Security Token Service, and Service Account Credentials APIs.
    Enable the APIs
  2. ワークロードの ID を表すサービスアカウントを作成します。ワークロードごとに専用のサービスアカウントを使用することをおすすめします。
    
    サービスアカウントは、Workload Identity プールと同じプロジェクトにある必要はありませんが、IAM アクセス権を付与する場合は、サービスアカウントを含むプロジェクトを参照する必要があります。
  3. 外部 ID にアクセスを許可するリソースに対するアクセス権をサービスアカウントに付与します。
2. サービスアカウントの権限借用を使用してアクセス権を付与する手順は次のとおりです。
  1. [Workload Identity プール] ページに移動します。
    
    [Workload Identity プール] に移動
  2. [アクセス権を付与] を選択します。
  3. [サービスアカウントにアクセス権を付与する] ダイアログで、[Grant access using Service Account impersonation] を選択します。
  4. [サービスアカウント] リストで、権限を借用する外部 ID のサービスアカウントを選択して、次の操作を行います。
  5. プール内のどの ID がサービスアカウントの権限を借用できるかを選択するには、次のいずれかを行います。
    
    Workload Identity プールの特定の ID のみにサービスアカウントの権限借用を許可するには、[フィルタに一致する ID のみ] を選択します。
    
    [属性名] リストで、フィルタリングする属性を選択します。
    
    [属性値] フィールドに、属性の想定値を入力します。たとえば、属性マッピング google.subject=assertion.sub を使用する場合は、属性名を subject に設定します。属性値には、外部 ID プロバイダによって発行されたトークンの sub クレームの値を設定します。
  6. 構成を保存するには、[保存]、[閉じる] の順にクリックします。
gcloud

gcloud CLI を使用して、特定の条件を満たす外部 ID に Workload Identity ユーザーロール（roles/iam.workloadIdentityUser）を付与するには、次のコマンドを実行します。
サブジェクト

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"
グループ

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"
属性

gcloud storage buckets add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \ --role=roles/storage.objectViewer \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"
次のように置き換えます。
- SERVICE_ACCOUNT_EMAIL: サービスアカウントのメールアドレス
- PROJECT_NUMBER: Workload Identity プールを含むプロジェクトのプロジェクト番号
- POOL_ID: Workload Identity プールのプール ID
- SUBJECT: google.subject にマッピングされている属性の想定値
- GROUP: google.groups にマッピングされている属性の想定値
- ATTRIBUTE_NAME: 属性マッピングのカスタム属性の名前
- ATTRIBUTE_VALUE: 属性マッピングのカスタム属性の値
注: メンバー ID には、プロジェクト ID ではなくプロジェクト番号を使用する必要があります。

認証情報の構成を作成する

gcloud CLI や Terraform などの Cloud クライアントライブラリやツールで Active Directory の認証情報を使用して Google Cloud の認証を行うには、Workload Authenticator for Windows を使用します。

Workload Authenticator for Windows は、Cloud クライアントライブラリと gcloud CLI などのツール用のプラグインとして機能するオープンソースツールです。

ツールまたはライブラリが新しい認証情報を必要とする場合は、バックグラウンドで Workload Authenticator が起動します。
Workload Authenticator は、OIDC、SAML、WS-Trust を使用して AD FS から新しいトークンまたは SAML アサーションを取得し、ツールやライブラリに返します。
ツールまたはライブラリは、Workload Identity 連携を使用して、トークンまたは SAML アサーションを有効期間の短い Google Cloud 認証情報と交換します。

Workload Authenticator for Windows を使用するには、認証情報の構成ファイルを作成する必要があります。このファイルに次の項目を定義します。

Workload Authenticator for Windows 実行可能ファイル（wwauth.exe）の場所と実行するパラメータ
使用する Workload Identity プールとプロバイダ
権限を借用するサービスアカウント

認証情報構成ファイルを作成するには、ワークロードを実行する Windows Server で次の操作を行います。

[スタート] ボタンを右クリックするか Win + X を押して、[Windows PowerShell] をクリックします。
Workload Authenticator for Windows をダウンロードして、ワークロードがアクセスできる場所に保存します。
```
(New-Object Net.WebClient).DownloadFile(
  "https://github.com/GoogleCloudPlatform/iam-windows-authenticator/releases/latest/download/wwauth.exe",
  "${env:ProgramData}\wwauth.exe")
```
Workload Authenticator for Windows を使用して認証情報の構成ファイルを作成した場合、そのファイルには実行可能ファイルのパスが含まれます。後で実行可能ファイルを削除または移動すると、ワークロードは実行可能ファイルを使用できなくなります。
wwauth.exe を起動します。
```
& ${env:ProgramData}\wwauth.exe
```
構成ダイアログが開きます。
[AD FS] タブを選択し、次の設定を入力します。
- Issuer URI of AD FS server: AD FS サーバーまたはファームの公開 URI。
```
https://ADFS_DOMAIN/adfs/
```
  ADFS_DOMAIN は、AD FS サーバーまたはサーバーファームのパブリックドメイン名に置き換えます。
次の設定は、使用するプロトコルによって異なります。
OIDC
- Protocol: AdfsOidc
- Relying party ID: デフォルトのままにします。
- Client ID: AD FS 内のサーバーアプリケーションのクライアント識別子（クライアント ID）。
SAML
- Protocol: AdfsSamlPost
- Assertion consumer service URL: https://sts.googleapis.com/v1/token
- Sign requests using certificate: disabled
WS-Trust
- Protocol: AdfsWsTrust
[Workload Identity] タブを選択し、次の設定を入力します。
- Project number: Workload Identity プールを含むプロジェクトのプロジェクト番号
- Pool ID: Workload Identity プールの ID
- Provider ID: Workload Identity プールプロバイダの ID
- サービスアカウントの権限借用: サービスアカウントの権限借用を使用する場合は、[有効] に設定します。
- メールアドレス: サービスアカウントの権限借用を使用する場合のサービスアカウントのメールアドレス
[AD FS] タブを選択し、[Relying Party ID] フィールドに Workload Identity プールプロバイダの URL が含まれていることを確認します。
[Apply] をクリックし、認証情報の構成ファイルを保存する場所を選択します。

サービスアカウントキーとは異なり、認証情報の構成ファイルにシークレットが含まれていないため、機密情報として扱う必要はありません。認証情報の構成ファイルの詳細については、https://google.aip.dev/auth/4117 をご覧ください。

これで、構成をテストする準備が整いました。

テストする Active Directory ユーザーを選択します。ここでは、ワークロードの Active Directory ユーザーまたは現在ログインしているユーザーが対象になります。
現在のユーザーで構成をテストするには、[Test] をクリックします。

別のユーザーでテストするには、[Test] > [Test configuration as user] を選択して、そのユーザーの認証情報を入力します。

次の手順を実行して Google Cloud の認証を試みます。
1. AD FS から OIDC トークンまたは SAML アサーションを取得します。
2. Google Security Token Service トークンを取得します。
3. サービスアカウントの権限借用を使用している場合は、サービスアカウントの権限を借用します。
認証が成功すると、「Test completed completed」というというメッセージが表示されます。

認証情報の構成を使用して Google Cloud にアクセスする

ツールとクライアントライブラリが認証情報の構成を使用できるようにするには、ワークロードを実行する Windows Server で次の手順を行います。

[スタート] ボタンを右クリックし、[ファイル名を指定して実行] をクリックします。
「sysdm.cpl」と入力して [OK] をクリックします。
[詳細設定] タブで、[環境変数] をクリックします。
[システム変数] で、次の 2 つの新しい変数を追加します。

名前値

GOOGLE_APPLICATION_CREDENTIALS 認証情報の構成ファイルのパス

GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES 1
[OK] をクリックします。
Workload Identity 連携をサポートし、認証情報を自動的に検索できるクライアントライブラリまたはツールを使用します。
C++
C++ 用 Google Cloud クライアントライブラリは、バージョン v2.6.0 から Workload Identity 連携をサポートしています。Workload Identity 連携を使用するには、バージョン 1.36.0 以降の gRPC でクライアントライブラリをビルドする必要があります。
Go
Go 用クライアントライブラリは、golang.org/x/oauth2 モジュールのバージョン v0.0.0-20210218202405-ba52d332ba99 以降を使用している場合、ID 連携をサポートします。

クライアントライブラリが使用しているこのモジュールのバージョンを確認するには、次のコマンドを実行します。
```
cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2
```
Java
Java 用クライアントライブラリは、com.google.auth:google-auth-library-oauth2-http アーティファクトのバージョン 0.24.0 以降を使用している場合、ID 連携をサポートします。

クライアントライブラリで使用しているこのアーティファクトのバージョンを確認するには、アプリケーションディレクトリで次の Maven コマンドを実行します。
```
mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
```
Node.js
Node.js 用クライアントライブラリは、google-auth-library パッケージのバージョン 7.0.2 以降を使用している場合、Workload Identity 連携をサポートします。

クライアントライブラリで使用されているこのパッケージのバージョンを確認するには、アプリケーションディレクトリで次のコマンドを実行します。
```
npm list google-auth-library
```
GoogleAuth オブジェクトを作成するときに、プロジェクト ID を指定できます。また、GoogleAuth で自動的にプロジェクト ID を検出することもできます。プロジェクト ID を自動的に検出するには、構成ファイルのサービスアカウントに、プロジェクト上でブラウザのロール（roles/browser）または同等の権限を持つロールが付与されている必要があります。詳細については、google-auth-library パッケージの README をご覧ください。
Python
Python 用クライアントライブラリは、google-auth パッケージのバージョン 1.27.0 以降を使用している場合、ID 連携をサポートします。

クライアントライブラリで使用されているこのパッケージのバージョンを確認するには、パッケージがインストールされている環境で次のコマンドを実行します。
```
pip show google-auth
```
認証クライアントのプロジェクト ID を指定するには、GOOGLE_CLOUD_PROJECT 環境変数を設定するか、クライアントがプロジェクト ID を自動的に検出するようにします。プロジェクト ID を自動的に検出するには、構成ファイルのサービスアカウントに、プロジェクト上でブラウザのロール（roles/browser）または同等の権限を持つロールが付与されている必要があります。詳細については、google-auth パッケージのユーザーガイドをご覧ください。
gcloud
Workload Identity 連携を使用して認証するには、gcloud auth login コマンドを使用します。
```
gcloud auth login --cred-file=FILEPATH.json
```
FILEPATH は、認証情報の構成ファイルのパスに置き換えます。

gcloud CLI での Workload Identity 連携は、gcloud CLI のバージョン 363.0.0 以降でサポートされています。
Terraform
バージョン 3.61.0 以降を使用している場合、Google Cloud プロバイダは Workload Identity 連携をサポートしています。
```
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 3.61.0"
    }
  }
}
```
gsutil
Workload Identity 連携を使用して認証を行うには、次のいずれかの方法を使用します。

gsutil と gcloud を併用する場合は、通常どおりログインします。
```
gcloud auth login --cred-file=FILEPATH.json
```
gsutil をスタンドアロンコマンドラインアプリケーションとして使用する場合は、.boto ファイルを編集して次のセクションを含めます。
```
[Credentials]
gs_external_account_file = FILEPATH
```
いずれの場合も、FILEPATH を認証情報の構成ファイルのパスに置き換えます。

gsutil での Workload Identity 連携は、gcloud CLI のバージョン 379.0.0 以降でサポートされています。
bq
Workload Identity 連携を使用して認証するには、次のように gcloud auth login コマンドを使用します。
```
gcloud auth login --cred-file=FILEPATH.json
```
FILEPATH は、認証情報の構成ファイルのパスに置き換えます。

bq での Workload Identity 連携は、gcloud CLI のバージョン 390.0.0 以降でサポートされています。

名前	値
`GOOGLE_APPLICATION_CREDENTIALS`	認証情報の構成ファイルのパス
`GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES`	`1`

次のステップ

Workload Identity 連携について確認する。
Workload Identity 連携の使用に関するベストプラクティスを確認する。
Workload Identity プールとプロバイダの管理方法を学習する。

Active Directory との Workload Identity 連携を構成する

AD FS を準備する

プロトコルを選択する

IWA の前提条件

ワークロードを登録する

OIDC

SAML または WS-Trust

SAML

WS-Trust

Workload Identity 連携を構成する

属性のマッピングと条件を定義する

OIDC

SAML または WS-Trust

OIDC

SAML または WS-Trust

Workload Identity のプールとプロバイダを作成する

必要なロール

コンソール

OIDC

SAML

gcloud

OIDC

SAML または WS-Trust

省略可: IdP から暗号化された SAML アサーションを受け入れる

Workload Identity 連携 SAML アサーション暗号鍵を作成する

暗号化された SAML アサーションを発行するように SAML 2.0 準拠の IdP を構成する

Workload Identity 連携暗号鍵を削除する

サポートされている SAML 暗号化アルゴリズム

ワークロードの認証を行う

外部ワークロードが Google Cloud リソースにアクセスできるようにする

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

コンソール

サブジェクト

グループ

属性

gcloud

サブジェクト

グループ

属性

サービス アカウントの権限借用

コンソール

gcloud

サブジェクト

グループ

属性

認証情報の構成を作成する

OIDC

SAML

WS-Trust

認証情報の構成を使用して Google Cloud にアクセスする

C++

Go

Java

Node.js

Python

gcloud

Terraform

gsutil

bq

次のステップ

サービスアカウントの権限借用