Skip to content
Latchkey

OIDC token exchange とは何か? アイデンティティを短命なアクセスと交換する

OIDC token exchange により、CI パイプラインは署名されたアイデンティティトークンを提示し、見返りに短命なクラウド認証情報を受け取ることができ、保存されたシークレットを排除します。

パイプラインにクラウドへの deploy を許可する古い方法は、長命なクラウドキーを CI シークレットとして保存することでした。これは漏洩し得て、永遠に機能する値です。OIDC token exchange はそれを置き換えます。CI プロバイダーが署名されたアイデンティティトークンを発行し、クラウドがそれを検証してプロバイダーを信頼し、短命な認証情報を返します。常設のシークレットが手渡されることは一切ありません。

ハンドシェイク

  • CI プロバイダーが job を記述した署名済み OIDC トークンを発行する。
  • パイプラインがそれをクラウド (AWS、GCP、Azure) に提示する。
  • クラウドが署名とトークンのクレームを検証する。
  • その job のための短命でスコープされた認証情報を返す。

保存されたシークレットを取り除く理由

クラウドは、あなたが保存した特定のキーではなく、アイデンティティプロバイダーとして CI プロバイダーを信頼します。パイプラインは実行ごとに自身が誰であるかを証明するので、CI シークレットの中に漏洩する長命なクラウドキーは存在しません。受け取る認証情報は job のためだけに存在します。

クレームによる信頼

OIDC トークンはクレームを持ちます。どの repo か、どの branch か、どの workflow か。クラウドの信頼ポリシーは特定のクレームを要求できるので、あなたの repo のあなたの main branch だけが deploy ロールを引き受けられます。これはアクセスを正確に正しいパイプラインコンテキストに紐付けます。

なぜ大きな意味を持つのか

それは 2 つの難しい問題、シークレットの保存とシークレットのローテーションを、何もない状態に折りたたみます。保存するシークレットもローテーションするシークレットもありません。認証情報がエフェメラルでアイデンティティベースだからです。これは CI からのクラウドアクセスに対する最もクリーンな答えです。

トークンは信頼できる runner から来なければならない

このモデル全体は、アイデンティティトークンが本物であることに依存します。それは本物の改ざんされていない job のために発行されなければならず、だからこそ信頼できる分離された build 環境で実行することが重要です。runner を制御した攻撃者は、実際にはあなたのものではない job のためにトークンを取得しようとする可能性があります。

重要なポイント

  • OIDC token exchange は署名されたアイデンティティトークンを短命なクラウド認証情報と交換します。
  • 保存された長命なクラウドキーを取り除くので、漏洩する永続的なものがありません。
  • 信頼ポリシーはトークンのクレーム (repo、branch) を鍵として、アクセスを正しい job に紐付けます。

関連ガイド