データやリソースを分析または管理できるプロダクトやサービスをユーザーに提供している場合、ユーザーが Google Cloud 環境内のデータやその他のリソースにアクセスしたいと思う可能性があります。このようなプロダクトやサービスとしては、次のようなものがあります。
- データ分析プロダクト: このようなプロダクトを使用して BigQuery でデータを分析することがあります。
- CI / CD プロダクトとサービス: このようなサービスを使用して、インフラストラクチャとアプリケーションを Google Cloud プロジェクトにデプロイすることがあります。
- ロボット プロセス自動化（RPA）: プロジェクトの作成、アクセス管理、Google Cloud の管理タスクの自動化などのワークフローで RPA を使用することがあります。
オンプレミスまたは Software as a Service（SaaS）プロダクトを Google Cloud で認証するために、これまではサービス アカウント キーが使用されてきましたが、こうした鍵の安全な管理と保管が難しい場合があります。
オンプレミス プロダクトまたは SaaS プロダクトのベンダーが Workload Identity 連携を使用して Google Cloud リソースへのアクセスを許可することで、ユーザーは Google Cloud リソースを安全に使用できるようになります。すでに Workload Identity 連携を使用しているサービスとしては、Terraform Cloud、GitHub、GitLab などがあります。
この記事では、Workload Identity 連携をサポートするようにプロダクトを拡張する方法について説明します。また、ベスト プラクティスについて紹介します。この記事は、Workload Identity 連携と OpenID Connect に精通していることを前提としています。
アーキテクチャ
Workload Identity 連携の目的は、サービス アカウント キーがなくても、ユーザーがプロダクトまたはサービスを Google Cloud 環境と連携できるようにすることです。これにより、ユーザーはプロダクトまたはサービスから提示された ID を使用して、Google Cloud リソースにアクセスできるようになります。
ユーザーが Workload Identity 連携を使用できるようにするには、プロダクトまたはサービスに OpenID Connect のサブセットを実装する必要があります。特に、次の条件を満たす ID トークンをワークロードが取得できるようにする必要があります。
- トークンでプロダクトまたはプラットフォーム内のワークロードを識別できる
- トークンでプロダクトまたはプラットフォームのインスタンス、テナント、またはインストールを識別できる
- トークンに、Workload Identity 連携でトークンの信頼性を検証するために使用できる暗号署名が含まれている
要件
Workload Identity 連携をサポートするには、プロダクトまたはサービスが次の要件を満たしている必要があります。
ワークロードが有効な ID トークンにアクセスできる。
ライフサイクル中、ワークロードはワークロードの ID を提示し、OpenID Connect 1.0 で定義された要件を満たしている ID トークンにアクセスできる必要があります。
ID トークンの存続期間は限定されています。ID トークンでワークロードの存続期間を長くするか、ワークロードが新しい ID トークンを定期的に取得できるようにする必要があります。
ID トークンはワークロードを一意に識別します。
ID トークンには、ワークロードを一意に識別するクレームが 1 つ以上含まれている必要があります。ワークロード ID は不変である必要があります。
マルチテナンシーをサポートするプロダクトまたはサービスの場合、テナントを一意に識別するクレームが 1 つ以上トークンに含まれている必要があります。テナント ID も不変である必要があります。
ID トークンは署名されますが、暗号化されません。
OpenID プロバイダ メタデータは一般公開されており、ID トークンから見つけることができます。
OpenID 発行元検出プロトコルで検出可能な、一般公開されているエンドポイントで OpenID プロバイダ構成ドキュメントを提供する必要があります。たとえば、ID トークンに値
https://service.example.com/v1/のissクレームが含まれている場合、https://service.example.com/v1/.well-known/openid-configurationに OpenID プロバイダ構成ドキュメントを提供する必要があります。また、エンドポイントは任意の IP アドレスからインターネット経由でアクセスできる必要があります。署名鍵は一般公開されており、OpenID プロバイダのメタデータから見つけることができます。
OpenID プロバイダ メタデータの
jwks_uriフィールドからアクセスできる公開エンドポイントの JSON Web Key Set（JWKS）ドキュメントを提供する必要があります。
ベスト プラクティス
Workload Identity 連携をサポートするようにプロダクトを拡張する場合は、次のベスト プラクティスを考慮してください。
ベスト プラクティス:
ID トークンとアクセス トークンを区別する。クライアント ライブラリと互換性のある方法で ID トークンを公開する。
テナント固有の発行元 URL を使用する。
ユーザーが ID トークンのオーディエンスを指定できるようにする。
ID トークンのクレームで再利用できない不変の識別子を使用する。
ID トークンにコンテキスト情報を含める。
ID トークンの有効期間を 30～60 分に制限する。
ID トークンとアクセス トークンを区別する
Workload Identity 連携のコンテキストでは、ID トークンの目的はワークロードの ID を表明することです。このトークンには、Workload Identity 連携でワークロードを識別し、区別するための十分な情報が含まれている必要があります。
ID トークンとは対照的に、アクセス トークンは通常さまざまな目的で使用されます。アクセス トークンはアクセスの判断に使用され、ワークロードにどの権限が付与されているか、どの API にアクセスが許可されているか、などに関する情報が含まれている場合があります。
プロダクトまたはサービスが現在、ワークロードの API 呼び出しなどの目的でアクセス トークンを使用している場合、これらのアクセス トークンは Workload Identity 連携に適していない可能性があります。アクセス トークンを ID トークンとして再利用するのではなく、ID トークンの定義と一致する 2 種類目のトークンを導入し、ワークロードで Workload Identity 連携に ID トークンを使用できるようにすることを検討してください。
クライアント ライブラリと互換性のある方法で ID トークンを公開する
Google Cloud クライアント ライブラリは、以下を含む複数のソースから自動的に ID トークンを取得できます。
- HTTP エンドポイント（URL 提供の認証情報）
- ローカル ファイル（ファイル提供の認証情報）
他のソースから ID トークンを取得するには、ユーザーがコードを変更するか、追加のツールやライブラリをデプロイする必要があります。クライアント ライブラリと互換性のある方法で ID トークンを公開することで、このような煩雑さを解消し、ユーザーが Workload Identity 連携を簡単に導入できるようになります。
テナント固有の発行元 URL を使用する
ワークロードの ID トークンに埋め込まれたクレームは、プロダクトやサービスの特定のインスタンス内で一意になっても、プロダクトやサービスの複数のインスタンス間では一意でない場合があります。たとえば、2 人のユーザーが、プロダクトまたはサービスを使用してワークロードをデプロイし、そのワークロードに同じ名前と ID を誤って割り当てているとします。
Workload Identity 連携は、ID トークンの発行元 URL（iss）を確認し、Workload Identity プールに 1 つの発行元からのトークンのみを許可することで、この一意性の問題を解決しようとします。
プロダクトまたはサービスがマルチテナンシーをサポートしている場合、複数のユーザーがプロダクトまたはサービスの単一インスタンスを共有し、ワークロードの ID トークンが同じ発行元 URL を使用することがあります。複数のテナントで同じ発行元 URL を使用すると、ユーザーがなりすまし攻撃を受ける可能性があります。たとえば、不正な行為者が独自のテナントにワークロードを作成し、被害者のテナント内のワークロードと同じ ID や名前を割り当て、独自のワークロードの ID トークンを使用して、被害者のワークロードの ID になりすまします。
ユーザーをなりすまし攻撃から保護するため、複数のテナントで同じ発行元 URL を使用しないでください。また、発行元 URL に一意のテナント ID を埋め込んでください（例: https://saas.example.com/tenant-123/）。
ユーザーに ID トークン オーディエンスの指定を許可する
ユーザーのワークロードの一部が、Google Cloud やその他のサードパーティ サービスへのアクセスを必要としていることがあります。ユーザーがプロダクトやサービスを複数の利用者と連携させる場合、ワークロードの ID トークンが誤って、または悪意のある利用者によって不正に利用される可能性があります。たとえば、不正な行為者が、ワークロードを阻止してサードパーティのサービス用の ID トークンを明らかにし、その ID トークンを Workload Identity 連携に使用する可能性があります。
このような混乱した代理攻撃の被害を避けるため、ID トークンには静的オーディエンス（aud クレーム）を使用しないでください。代わりに、ID トークンの取得時にワークロードがオーディエンスを指定できるようにします。また、ワークロードがリクエストできるオーディエンスの許可リストを維持することもできます。
デフォルトでは、Workload Identity 連携は、ID トークンのオーディエンスが URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID と一致することを前提としています。ワークロードが ID トークンのオーディエンスとして URL を使用できることと、オーディエンスの長さが 180 文字以下であることを確認してください。
ID トークン クレームに再利用できない不変の ID を使用する
ワークロードのいずれかに Google Cloud リソースへのアクセス権を付与する場合は、サブジェクト、グループ、またはカスタム属性でワークロードの ID を参照する IAM バインディングを作成する必要があります。ワークロードの ID のサブジェクト、グループ、カスタム属性は、ワークロードの ID トークン内のクレームから取得されます。
変更可能なクレームを参照する IAM バインディングを作成した場合、クレームの値が変更されたときに、ワークロードが誤ってアクセスできなくなることがあります。たとえば、ユーザーがワークロードの名前を参照する IAM バインディングを作成するとします。また、ワークロードの名前を変更すると、IAM バインディングが適用されなくなることがあります。
また、不正な行為者は、ワークロードの名前を意図的に変更したり、別のワークロードの ID になりすますためにワークロードの環境を変更して、他のリソースへの不正アクセスを試みる可能性があります。
ユーザーがなりすまし攻撃を防止できるように、ID トークンに不変の ID が含まれています。これは再利用できません。
ID トークンにコンテキスト情報を含める
ワークロードに Google Cloud リソースへの無条件アクセス権を付与する代わりに、ワークロードが特定の追加条件を満たした場合にのみ Google 認証情報を取得できるように、アクセスを制限できます。
このような制限を構成するには、コンテキスト情報を含む追加のクレームを ID トークンに含めます。コンテキスト情報の例:
- ワークロードを所有または開始したユーザーに関する情報
- ワークロードが開始された理由と方法
- 現在ワークロードによって処理されているリクエスト
これらのクレームを使用して、属性条件またはプリンシパル ID を構成できます。
ID トークンの有効期間を 60 分に制限する
ID トークンの存続期間は限定されています。これは、exp クレームによって判定されます。ワークロードが ID トークンを使用してトークン交換を実行する場合、Workload Identity 連携は ID トークンの exp クレームを検証し、入力トークンである限り有効な STS トークンを発行します（ただし、最大 1 時間）。
1 時間を超える有効な ID トークンの使用は、Workload Identity 連携には影響しませんが、ID トークンが誤って漏洩した場合のリスクが高まる可能性があります。ライフタイムを 1 時間よりも大幅に短くすると、このようなリスクを軽減できますが、トークンの交換が頻繁に発生し、パフォーマンスが低下する可能性もあります。
次のステップ
- Workload Identity 連携について確認する。
- Workload Identity 連携の使用に関するベスト プラクティスを確認する。