Workload Identity 連携

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

ID 連携は、Amazon Web Services(AWS)や、OpenID Connect(OIDC)をサポートする任意の ID プロバイダ(Microsoft Azure など)で使用できます。

ID 連携が必要な理由

従来、Google Cloud の外部で実行されているアプリケーションは、サービス アカウント キーを使用して Google Cloud リソースにアクセスしていました。サービス アカウント キーは非常に強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。

ID 連携を使用すると、Identity and Access Management(IAM)を使用し、外部 ID に対して、サービス アカウントになりすます機能を含む IAM ロールを付与できます。これにより、有効期間の短いアクセス トークンを使用してリソースに直接アクセスでき、サービス アカウント キーに関連するメンテナンスとセキュリティの負担が軽減されます。

Workload Identity プール

Workload Identity プールは、外部 ID のコレクション用のコンテナです。

1 つのプロジェクトに複数の Workload Identity プールを含めることができ、各プールは異なるリソースにアクセスできます。これにより、同じプール内で関連する ID をグループ化して、リソースに対するきめ細かいアクセス権をその ID に付与することで、最小権限の原則に従うことができます。

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

Workload Identity プロバイダ

Workload Identity プロバイダは、Google Cloud と外部 ID プロバイダとの関係を表すエンティティです。プロバイダの例は以下のとおりです。

  • AWS
  • Azure Active Directory
  • オンプレミスの Active Directory
  • Okta
  • Kubernetes クラスタ

Workload Identity 連携は、OAuth 2.0 トークン交換の仕様に従います。外部 ID プロバイダの認証情報をセキュア トークン サービスに提供します。セキュア トークン サービスにより認証情報の ID が確認されると、引き換えに連携トークンが返されます。

属性のマッピング

認証情報には通常、その認証情報によって識別される ID に関する情報(名前、メールアドレス、ユーザー ID など)を提供する属性が含まれます。属性のマッピングでは、外部トークンの属性を Google トークンに適用します。これにより、IAM によって外部プロバイダのトークンが使用され、Google Cloud リソースへのアクセスが承認されます。

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

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

属性のマッピングでは、Common Expression Language がサポートされているため、外部認証情報に基づいて新しいカスタム属性を作成する、または既存の属性を読みやすくできます。たとえば、次のマッピングでは、Amazon リソース名(ARN)に :instance-profile/Production が含まれているかどうかに基づいて、environment 属性を定義しています。

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

条件

条件を使用すると、ワークロード ID プールを使用して認証できる ID を制限できます。CEL 式を使用すると、リクエストの認証情報の属性を調べて、アクセスを許可するかどうかを判断できます。

条件は、次のような複数のシナリオで使用します。

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

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

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

attribute.aws_role == "role-mapping"

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

トークン交換フローは連携アクセス トークンを返します。このトークンを使用すると、サービス アカウントの権限を借用し、有効期間の短い OAuth 2.0 アクセス トークンを取得できます。有効期間の短いアクセス トークンを使用すると、サービス アカウントがアクセスできる Google Cloud APIs を呼び出すことができます。

サービス アカウントの権限を借用するには、ワークロードに必要なロールを使用して、サービス アカウントの Workload Identity ユーザーロール(roles/iam.workloadIdentityUser)を外部 ID に付与します。Workload Identity プール内のすべての ID にロールを付与することや、属性に基づいて特定の外部 ID にロールを付与することが可能です。

次の表は、ロール付与の一般的なシナリオを表したものです。

シナリオ 形式
単一の ID principal://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/subject/subject-name
グループ内のすべての ID principalSet://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/group/group-name
属性のマッピングを使用して定義された属性を持つすべての ID principalSet://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/attribute.attribute-name/attribute-value
プール内のすべての ID principalSet://iam.googleapis.com/projects/project-number/locations/global/workloadIdentityPools/pool-id/*

次のステップ