Workload Identity Federationとは?

workload identity federationを使うと、クラウドの外部で実行されているワークロード - CIのjobなど - が、保存されたキーを一切使わずに、独自のトークンでそのクラウド内のアイデンティティを引き受けられます。

クラウドプロバイダーは、外部システムに長期間有効な認証情報を保持させることなくアクセスを付与したいと考えています。workload identity federationは信頼関係を確立し、外部トークン(多くの場合OIDCトークン)をクラウドアクセスと交換できるようにします。

federationの考え方

CI用のキーを持つクラウドユーザーを作成する代わりに、federationを行います。つまり、外部の発行者(CIプラットフォーム)からのトークンを信頼し、そのclaimをクラウドのroleやアイデンティティにマッピングするようクラウドに指示します。

OIDCとの関係

OIDCはトークンの形式とプロトコルであり、workload identity federationはそれらのトークンを消費するクラウド側の設定です。実際には、federationを一度設定すれば、各CIのjobはOIDCを使ってそのアイデンティティを引き受けます。

設定する内容

CIプラットフォームの発行者を信頼するidentity providerのエントリ。
条件で使う属性またはclaimのマッピング(repo、branch)。
federatedワークロードが引き受けられるroleまたはサービスアイデンティティ。

小さな例

Google Cloudでは、GitHubの発行者を信頼するproviderを持つworkload identity poolを作成し、repository claimをマッピングして、それをservice accountにバインドします。するとそのrepoのCIのjobは、キーファイルなしでservice accountをimpersonateします。

クラウド間での呼び方

各プロバイダーは異なる名前を付けています - AWSはIAM OIDC roles、GoogleはWorkload Identity Federation、Azureはfederated credentialsと呼びます - が、モデルは同じです。外部のトークン発行者を信頼し、claimをアイデンティティにマッピングします。

重要なポイント

federationにより、外部ワークロードは保存されたキーなしでクラウドのアイデンティティを引き受けられます。
OIDCはトークンを提供し、federationはクラウド側の信頼設定です。
トークンのclaimをroleにマッピングし、repoとbranchでアクセス範囲を絞ります。