Workload Identity の概要
Workload Identity を使用すると、クラスタ内のアプリケーションごとにきめ細かい ID と認可を割り当てることができます。Workload Identity は、GKE on Azure 内で実行されているアプリケーションで Azure と Google Cloud サービスにアクセスする場合に推奨される方法です。
すべての GKE クラスタで Workload Identity は有効になっています。
Kubernetes サービス アカウント
Workload Identity は、ID 連携を実装するか、信頼またはロールを外部プロバイダに委任します。各クラスタには、組み込みの OpenID Connect（OIDC）プロバイダがあります。クラスタ内で Pod が実行される場合、Kubernetes サービス アカウントを使用して実行されます。Pod は、バインドされたサービス アカウント トークン ボリュームを使用して、Kubernetes サービス アカウントのトークン（有効期間の短い認証情報を含む）を取得するように構成できます。
OpenID Connect プロバイダ
各クラスタは OpenID Connect（OIDC）プロバイダとして機能します。このプロバイダを使用すると、OIDC を使用して ID 連携をサポートするサービスに Kubernetes サービス アカウントの認証情報を提供できます。
このプロバイダの発行者 URI は、OIDC ディスカバリ エンドポイントとしても機能します。サービスは、このディスカバリ エンドポイントを使用して JSON Web Key Set（JWKS）を取得できます。JWKS は、Kubernetes サービス アカウントの認証情報を検証するための公開鍵情報を提供します。
Google Cloud IAM の ID プールとプロバイダ
Google Cloud IAM は、OIDC を使用した ID 連携をサポートしています。すべての GKE クラスタは、Workload Identity プール PROJECT_ID.svc.id.goog で ID プロバイダとして構成されます。
Workload Identity プールとプロバイダの名前を取得する方法については、Google Cloud で Workload Identity を使用するをご覧ください。
Workload Identity に代わる方法
GKE on Azure からサービスにアクセスするには、複数の方法があります。次の方法は複雑になるため、おすすめしません。
認証情報をエクスポートして Kubernetes Secret として保存する。この場合、Azure IAM とクラスタの両方で保存されている認証情報を手動でローテーションする必要があります。さらに、認証情報が攻撃者に盗まれ、悪用される可能性があります。
ノードプールの基盤となるインスタンスに認証情報を関連付ける。この場合、同じノード上で実行されているすべてのワークロードが認証情報を共有するため、ワークロードが必要とする権限よりも多くの権限が作成される可能性があります。インスタンスの権限へのアクセスをブロックするために、GKE クラスタは Pod からインスタンス メタデータ サービスへのアクセスをブロックします。