TERM 046
Workload Identity
アプリへ、長期鍵ではなく一時的な身元を与える
Workload Identityは、アプリケーション、CI/CDパイプライン、コンテナなどの実行主体に対して安全なアイデンティティ（身元）を与え、有効期限の短い一時的な認証情報（クレデンシャル）を使ってクラウドのリソースへアクセスさせる仕組みです。長期有効な固定アクセスキーの管理や漏えいリスクを排除できます。
アプリや処理に一時的な身元と権限を与える仕組みの全体像。
CONTENTSこの記事の目次＋
01 — DEFINITION
Workload Identityとは
何か
Workload Identityは、アプリケーション、CI/CDパイプライン、コンテナなどの実行主体に対して安全なアイデンティティ（身元）を与え、有効期限の短い一時的な認証情報（クレデンシャル）を使ってクラウドのリソースへアクセスさせる仕組みです。長期有効な固定アクセスキーの管理や漏えいリスクを排除できます。
02 — HOW IT WORKS
仕組みを
3段階で見る
細部へ入る前に、入力から結果までの役割を順番に捉えます。
実行元を証明
GitHub Actionsなどの実行基盤（外部IdP）が、ワークロードの属性情報（リポジトリ名やブランチ名など）を含む署名付きトークンを発行する。
→一時Credentialへ交換
クラウド側が事前に設定された信頼関係と属性条件を照合し、短時間だけ有効なアクセストークンを返却する。
→権限内で利用
引き受けたIAMロールに許可されている必要なクラウドリソースにのみアクセスする。
Workload Identityを理解するときの、最小の処理単位です。
03 — ESSENTIALS
押さえるべき
3つの要点
名前だけでなく、この3点の関係まで理解すると実装へつなげやすくなります。
発行元への信頼関係
どの実行プラットフォームやIDプロバイダ（IdP）が発行したOIDCトークンを信頼するか、事前に信頼ポリシーを設定します。
属性による絞り込み
リポジトリ名、ブランチ名、Kubernetesの名前空間やサービスアカウント名などの属性をもとにアクセス対象を厳密に制限します。
短命な認証情報
発行されるアクセストークンの有効期限を1時間程度に限定することで、万が一漏えいした場合の不正利用リスクを極小化します。
04 — REAL WORLD EXAMPLE
GitHub Actionsからクラウドへ安全にデプロイする
リポジトリのSecretsに長期のサービスアカウント秘密鍵を直接保存することなく安全に認証します。
- 01
GitHub Actionsがジョブ情報（リポジトリやブランチ）を含むOIDCトークンを発行する
- 02
クラウド側が許可されたリポジトリとブランチからの要求であることを検証する
- 03
デプロイに必要な最小限の権限を持つ一時アクセストークンへ交換する
05 — WATCH OUT
理解するときの
注意点
便利な仕組みほど、守備範囲と失敗の前提を明確にします。
信頼条件を広げすぎない
Organization全体ではなく、Repository、Branch、Environmentまで絞ります。
交換後のIAM権限も最小化する
どれだけ認証経路が安全であっても、引き受けるIAMロールの権限が過大であれば侵害時の被害が拡大します。必要最小限の操作のみを許可するポリシーを徹底します。
IN ONE SENTENCE
Workload Identityとは？
アプリや処理に一時的な身元と権限を与える仕組み。