Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Workforce Identity 連携（BYOID）を構成する

このガイドでは、Workforce Identity 連携と Workload Identity 連携を使用して、マルチパーティコンピューティング API の Bring Your Own Identity（BYOID）を構成する方法について説明します。ID 連携を使用すると、人間のユーザーと自動署名者ワークロードは、組織の外部 ID プロバイダ（IdP）（Okta、Microsoft Entra ID、Ping Identity など）を使用してマルチパーティコンピューティングを認証できます。Google アカウントを作成したり、有効期間の長いサービスアカウントキーを管理したりする必要はありません。

概要

ID 連携は、次のレイヤにわたってマルチパーティコンピューティングの多層防御セキュリティモデルと統合されます。

Edge Identity and Access Management（IAM）認可: 呼び出し元は、外部の OpenID Connect（OIDC）または SAML 2.0 IdP の認証情報を Google Cloud Security Token Service（Security Token Service）と交換して、有効期間の短い連携アクセストークンを取得します。 Google Cloud API Gateway は、リクエストをマルチパーティコンピューティングインスタンスに転送する前に、フェデレーションプリンシパル URI に対して IAM ロールバインディングを評価し、Cloud Audit Logs のフェデレーション ID（principalSubject）を伝播します。
職務分掌と暗号承認: IAM ロールは、管理プロビジョニング（roles/mpc.admin）、運用参加（roles/mpc.editor）、読み取り専用監視（roles/mpc.viewer）を分離します。インスタンス内では、管理者、ポリシー作成者、署名者にも、ユーザーの代わりに動作するメソッドをインスタンスがチェックするロール（ADMIN、POLICY_AUTHOR、SIGNER）を持つユーザーが必要です。また、承認は、そのユーザーに登録されている承認鍵で署名する必要があります。詳細については、リクエストの承認方法をご覧ください。

呼び出し元のタイプに応じて、次の 2 つの ID 連携メカニズムを使用できます。

Workforce Identity 連携（locations/global/workforcePools/...）: 企業の IdP にマッピングされた組織レベルの Workforce プールを使用して、人間のユーザー（管理者、ポリシー作成者、署名者、コンプライアンス）を認証します。このガイドでは、Workforce Identity 連携をエンドツーエンドで構成する方法について説明します。
Workload Identity 連携（projects/.../locations/global/workloadIdentityPools/...）: プロジェクトレベルの Workload Identity プールを使用して、自動化されたワークロード（AWS、Azure、Kubernetes で実行されるヘッドレス共同署名者デーモンなど）を認証します。

IAM ロールがマルチパーティコンピューティングのペルソナにどのようにマッピングされるかについては、セキュリティと認可をご覧ください。

始める前に

始める前に、以下のものが揃っていることをご確認ください。

マルチパーティコンピューティングにオンボーディングされた Google Cloud 組織とコンシューマープロジェクト。
gcloud CLI と jq がインストールされ、gcloud が次のロールを持つ管理アカウントで認証されている。
- Google Cloud 組織に対する従業員プール管理者（roles/iam.workforcePoolAdmin）（ステップ 1 で新しい従業員プールを作成する場合）。
- コンシューマープロジェクトに対するプロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）と Service Usage 管理者（roles/serviceusage.serviceUsageAdmin）。

コンシューマプロジェクトで有効になっている必要な API:

gcloud services enable mpc.googleapis.com iam.googleapis.com sts.googleapis.com \
  --project="my-project"

企業の IdP で構成された外部 OIDC または SAML 2.0 アプリケーション。gcloud CLI でインタラクティブなブラウザログインを使用する場合は、IdP アプリケーションで Google Cloud リダイレクト URI を構成します（Okta と Microsoft Entra ID の設定ガイドをご覧ください）。

設定

次の変数を更新して、このガイド全体のコマンドに値を入力します。

必須のセットアップパラメータ

これらのパラメータは、 Google Cloud 環境と外部 IdP の構成に合わせてカスタマイズします。

パラメータ	値	説明
組織 ID	`123456789012`	数値の Google Cloud 組織 ID。
プロジェクト ID	`my-project`	マルチパーティコンピューティングインスタンスに登録されているコンシューマープロジェクト ID。
ドメイン ID	`67317436-0f29-ba9e-9146-d11c0bd8df9b`	マルチパーティコンピューティングインスタンスに割り当てられた一意のドメイン ID。
インスタンスパス ID	`mpc-unit-bob-123`	マルチパーティコンピューティングインスタンスに割り当てられたインスタンスパス ID。
ロケーション	`us-central1`	デプロイの場所（`us-central1`）。詳細については、マルチパーティコンピューティングのロケーションをご覧ください。
Workforce プール ID	`mpc-workforce-pool`	組織レベルの Workforce Identity プール ID。
プロバイダ ID	`mpc-oidc-provider`	Workforce Identity プールプロバイダ ID。
IdP 発行元 URI	`https://idp.example.com`	外部 OIDC IdP 発行者 URI。
IdP クライアント ID	`mpc-client`	外部 IdP で構成された OAuth 2.0 クライアント ID。

ステップ 1: Workforce Identity プールとプロバイダを構成する

Workforce Identity プール（locations/global/workforcePools/mpc-workforce-pool）は、エンタープライズ IdP テナントにマッピングされる組織レベルのリソースです。プロジェクトやロールごとに個別の Workforce プールを作成する必要はありません。

Google Cloud 組織に Workforce Identity プールを作成します。

gcloud iam workforce-pools create "mpc-workforce-pool" \
  --organization="123456789012" \
  --location="global" \
  --display-name="MPC Workforce Pool"

外部 IdP を信頼し、サブジェクトクレームとグループクレームをマッピングする OIDC Workforce プールプロバイダを作成します。
```
gcloud iam workforce-pools providers create-oidc "mpc-oidc-provider" \
  --workforce-pool="mpc-workforce-pool" \
  --location="global" \
  --display-name="MPC Enterprise OIDC Provider" \
  --issuer-uri="https://idp.example.com" \
  --client-id="mpc-client" \
  --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups" \
  --web-sso-response-type="id-token" \
  --web-sso-assertion-claims-behavior="only-id-token-claims"
```
注: デフォルトでは、Security Token Service は IdP の /.well-known/openid-configuration エンドポイントから公開署名鍵を検出してローテーションします。一般公開されていないオフラインまたは合成 OIDC 発行元でテストする場合は、--jwk-json-path="<var>PATH_TO_JWK_FILE</var>" を渡し、<var>PATH_TO_JWK_FILE</var> を発行元の公開 JSON Web Key Set（JWKS）ファイルのローカルパスに置き換えます。SAML 2.0 プロバイダの場合は、gcloud iam workforce-pools providers create-saml と --idp-metadata-path を使用します。

ステップ 2: 連携プリンシパルに IAM ロールを付与する

MPC API を呼び出すには、連携プリンシパルに、コンシューマープロジェクト（my-project）に対する 2 種類の IAM ロールバインディングが必要です。

Service Usage コンシューマー（roles/serviceusage.serviceUsageConsumer）。フェデレーション ID が API の割り当てと課金をコンシューマープロジェクトに関連付けることを認可します。
マルチパーティコンピューティングロール（roles/mpc.admin、roles/mpc.editor、roles/mpc.viewer）。特定のマルチパーティコンピューティングオペレーションを認可します。

本番環境では、Workforce プール内の個別の IdP グループに IAM ロールをバインドします。

# 1. Allow members of the workforce pool to consume APIs through the consumer project
gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/serviceusage.serviceUsageConsumer" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/*"

# 2. Grant MPC Admin to the enterprise administrators group
gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/mpc.admin" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-admins"

# 3. Grant MPC Editor to Policy Authors and Signers groups
gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/mpc.editor" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-policy-authors"

gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/mpc.editor" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-signers"

# 4. Grant MPC Viewer to the Compliance group
gcloud projects add-iam-policy-binding "my-project" \
  --role="roles/mpc.viewer" \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/group/mpc-auditors"

注意: グループクレームを出力しない合成ユーザーを使用して、分離されたテスト環境でマルチパーティコンピューティングを評価する場合は、roles/mpc.admin を単一のサブジェクト（principal://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/subject/<var>USER_SUBJECT</var>。<var>USER_SUBJECT</var> はユーザーの sub クレーム）または専用のテストプール（principalSet://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/*）にバインドできます。本番環境の Workforce プールで roles/mpc.admin を /* にバインドしないでください。バインドすると、企業の IdP テナントのすべてのユーザーに管理者権限が付与されます。

自動署名者ワークロード（Workload Identity 連携）

Google Cloud の外部（AWS、Azure、Kubernetes など）で自動共同署名者デーモンを実行する場合は、プロジェクトスコープの Workload Identity プールとプロバイダを構成します。ワークロードプリンシパル（principal://iam.googleapis.com/projects/<var>PROJECT_NUMBER</var>/locations/global/workloadIdentityPools/<var>WORKLOAD_POOL_ID</var>/subject/<var>SIGNER_NODE_SUBJECT</var>。<var>PROJECT_NUMBER</var>、<var>WORKLOAD_POOL_ID</var>、<var>SIGNER_NODE_SUBJECT</var> をプロジェクト番号、ワークロードプール ID、ワークロード sub クレームに置き換えます）に roles/serviceusage.serviceUsageConsumer と roles/mpc.editor を付与し、gcloud iam workload-identity-pools create-cred-config を使用してアプリケーションのデフォルト認証情報ファイルを生成します。

フェデレーション ID を v1beta ユーザーとして追加する

v1beta API では、このステップの IAM ロールにより、フェデレーション ID がインスタンスを呼び出すことができます。インスタンス内で管理者、ポリシー作成者、署名者として操作するには、ID にユーザーも必要です。インスタンスは、呼び出し元のプリンシパルを各ユーザーの principal フィールドと照合して、呼び出し元を識別します。

Workforce Identity フェデレーション ID の場合は、principal を ID のサブジェクトプリンシパル識別子に設定します。

principal://iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/subject/SUBJECT_ID

SUBJECT_ID は、プロバイダが google.subject にマッピングする値に置き換えます。ステップ 1 の属性マッピングでは、ユーザーの ID トークンの sub クレームです。

principal を設定する際は、次の点に注意してください。

principalSet:// 識別子ではなく、principal:// 識別子を使用します。ユーザーは 1 人の個人です。principalSet://.../group/mpc-signers などのグループ ID とプール ID は IAM ロールバインディングで機能しますが、呼び出し元と一致することはないため、これらを使用して作成されたユーザーはインスタンスで操作できません。
件名と完全に一致する。インスタンスは、従業員とワークロードのサブジェクトを大文字と小文字を区別して比較するため、IdP が発行したサブジェクトをコピーします。Google アカウントのメールアドレス（alice@example.com など）は、大文字と小文字を区別せずに比較されます。
principal を後で変更することはできません。ユーザーの ID を変更するには、ユーザーを無効にして新しいユーザーを作成します。

ステップ 3: 認証して連携アクセストークンを取得する

MPC API は、IdP から OIDC トークンまたは SAML アサーションを直接受け入れません。マルチパーティコンピューティングインスタンスエンドポイント（*.mpc.goog）を呼び出す前に、Security Token Service で IdP 認証情報を連携 Google Cloud アクセストークンと交換します。

連携アクセストークンは、アプリケーションのデフォルト認証情報（ADC）と gcloud CLI を使用して自動的に取得および管理できます。また、Security Token Service API を使用してプログラムで取得および管理することもできます。

アプリケーションのデフォルト認証情報と gcloud CLI

本番環境のクライアントアプリケーションとインタラクティブな CLI セッションでは、構成ファイルを使用して、Google Cloud SDK と Cloud クライアントライブラリがバックグラウンドで Security Token Service トークンの交換、キャッシュ保存、更新を自動的に処理するようにします。

オプション A: インタラクティブなブラウザログイン

ログイン構成ファイルを生成し、gcloud CLI とアプリケーションのデフォルト認証情報（ADC）の両方を企業の IdP で認証します。

gcloud iam workforce-pools create-login-config \
  "locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
  --activate \
  --output-file="login-config.json"

gcloud config set billing/quota_project "my-project"
gcloud auth login --login-config="login-config.json"
gcloud auth application-default login --login-config="login-config.json"

オプション B: 認証情報構成ファイル（ADC）を使用した非インタラクティブなログイン

トークンの有効期限が切れる前に、外部プロセスがローカルファイル（/var/run/secrets/tokens/oidc-token など）で署名付き OIDC トークンを提供して更新する場合は、外部認証情報の構成ファイルを生成します。

gcloud iam workforce-pools create-cred-config \
  "locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
  --subject-token-type="urn:ietf:params:oauth:token-type:id_token" \
  --credential-source-file="/var/run/secrets/tokens/oidc-token" \
  --workforce-pool-user-project="my-project" \
  --output-file="credential-config.json"

export GOOGLE_APPLICATION_CREDENTIALS="$(pwd)/credential-config.json"

curl リクエストのアクセストークンをエクスポートします。

オプション A またはオプション B を完了したら、ADC から ACCESS_TOKEN に連携アクセストークンをエクスポートします。

export ACCESS_TOKEN="$(gcloud auth application-default print-access-token)"

直接 REST STS トークン交換

Google Cloud SDK を使用せずにカスタムクライアントを統合する場合は、署名付き OIDC ID トークン（<var>IDP_ID_TOKEN</var>）を Security Token Service と直接交換します。options フィールドに userProject を含めて、 Google Cloud がトークンをコンシューマープロジェクトに関連付けるようにします。

# Set IDP_ID_TOKEN to the signed OIDC JWT assertion from your external IdP
# export IDP_ID_TOKEN="eyJhbGciOiJSUzI1NiIs..."

STS_RESPONSE=$(curl -sS -X POST "https://sts.googleapis.com/v1/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  --data-urlencode "audience=//iam.googleapis.com/locations/global/workforcePools/mpc-workforce-pool/providers/mpc-oidc-provider" \
  --data-urlencode "scope=https://www.googleapis.com/auth/cloud-platform" \
  --data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:access_token" \
  --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:id_token" \
  --data-urlencode "subject_token=${IDP_ID_TOKEN}" \
  --data-urlencode 'options={"userProject":"my-project"}')

export ACCESS_TOKEN=$(echo "${STS_RESPONSE}" | jq -er '.access_token') || echo "${STS_RESPONSE}" | jq .

ステップ 4: 連携 API アクセスを確認する

マルチパーティコンピューティングインスタンスのユーザーを一覧表示して、連携認証情報、userProject 属性、IAM ロールバインディングが機能していることを確認します。mpc.googleapis.com/users.list は roles/mpc.viewer、roles/mpc.editor、roles/mpc.admin に含まれているため、承認された連携ペルソナは、このチェックを実行できます。

curl -sS -X GET \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "X-Goog-User-Project: my-project" \
  "https://67317436-0f29-ba9e-9146-d11c0bd8df9b.us-central1.mpc.goog/v1beta/projects/my-project/locations/us-central1/instances/mpc-unit-bob-123/users" | jq .

200 OK JSON レスポンス（新しいインスタンスの {} または users のリスト）は、フェデレーション ID が認証され、マルチパーティコンピューティングインスタンスを呼び出す権限があることを確認します。

このチェックでは IAM のみが使用されます。インスタンスがユーザーとしての ID も認識していることを確認するには、返されたユーザーの 1 人の principal フィールドに principal:// 識別子があることを確認します。詳細については、フェデレーション ID を v1beta ユーザーとして追加するをご覧ください。

トラブルシューティング

連携認証情報を使用してマルチパーティコンピューティングを呼び出すときに認証エラーまたは権限エラーが発生した場合は、次の要件を確認してください。

ユーザープロジェクトの帰属（`401 UNAUTHENTICATED: Unable to determine client project number`）

原因: 組織レベルの Workforce プールの認証情報は、トークン交換時またはリクエスト時にユーザープロジェクトが指定されていない限り、1 つの Google Cloud プロジェクトに本質的にバインドされません。
解決策: Security Token Service トークン交換リクエストの本文に options: {"userProject": "<var>PROJECT_ID</var>"}（または gcloud iam workforce-pools create-cred-config の --workforce-pool-user-project）を含め、MPC API 呼び出しに X-Goog-User-Project: <var>PROJECT_ID</var> ヘッダーを含めます。

Service Usage 権限（`403 PERMISSION_DENIED`）がありません

原因: 連携プリンシパルまたはグループに、API の使用量を userProject または X-Goog-User-Project で指定されたコンシューマープロジェクトに関連付ける権限がありません。
解決策: コンシューマプロジェクトの principal:// メンバーまたは principalSet:// メンバーに roles/serviceusage.serviceUsageConsumer を付与します（ステップ 2 をご覧ください）。

コンシューマープロジェクトの不一致（`403 PERMISSION_DENIED: Project is not allowed to call the API through this host`）

原因: 各専用マルチパーティコンピューティングインスタンスエンドポイントは、そのインスタンス用に構成されたコンシューマープロジェクトからのリクエストのみを受け入れます。
解決策: リクエスト URL パスと userProject / X-Goog-User-Project ヘッダーの両方の <var>PROJECT_ID</var> が、マルチパーティコンピューティングインスタンスにプロビジョニングされたコンシューマープロジェクトと一致していることを確認します。

認証情報が無効です（`401 UNAUTHENTICATED: Request credential is invalid`）

原因: サードパーティの OIDC トークンまたは SAML アサーションが、Security Token Service を使用して交換されることなく、マルチパーティコンピューティングエンドポイントに直接送信されました。
解決策: https://sts.googleapis.com/v1/token を介して IdP 認証情報を交換し（またはアプリケーションのデフォルト認証情報を使用し）、結果の Google Cloud アクセストークンを Authorization: Bearer ヘッダーに渡します。

ドメイン制限付き共有ポリシーがロールバインディングをブロックする（`400 FAILED_PRECONDITION`）

原因: Google Cloud 組織が constraints/iam.allowedPolicyMemberDomains 組織ポリシーを適用しています。これにより、プロジェクトで IAM ロールを付与できるプリンシパルドメインが制限されます。
解決策: 組織ポリシー管理者に、コンシューマープロジェクトまたは組織の許可されたポリシーメンバードメインに Workforce プールのプリンシパルセットを追加するよう依頼するか、constraints/iam.allowedPolicyMemberDomains が Workforce プールを許可しているプロジェクトでテストします。

次のステップ

ユーザー、チーム、トランザクションポリシー、鍵を作成し、フェデレーション ID でトランザクションに署名するには、マルチパーティコンピューティングユーザーガイドに沿って操作します。各ユーザーのプリンシパルを、フェデレーション ID を v1beta ユーザーとして追加するで説明されている principal:// 識別子に設定します。
ユーザーガイドでは、gcloud auth print-access-token を使用して各ペルソナのアクセストークンを取得します。これは、アプリケーションのデフォルト認証情報ではなく、gcloud CLI 認証情報を使用します。ステップ 3 のオプション A に示すように、gcloud auth login --login-config を使用して各連携ユーザーをログインさせます。
ユーザーロール、IAM 権限、リソースレベルの条件の詳細については、セキュリティと認可をご覧ください。