要約

  • 改訂 07 は、複数の資格情報を取得できない、またはワークロードが audience を指定できない場合を除き、JWT に複数の audience を持たせてはならないとする。改訂 06 は単一 audience を SHOULD としていた。
  • 問題は受信者間のなりすましである。同じ Bearer トークンを受け取った当事者は、それを別の受理者へ提示できる。
  • 能力例外の記録には、分離不能の理由、受信者グラフ、寿命と到達範囲、各受信者の検証、補償策、再審査日、例外を終了する条件が必要になる。

一つの Pod が projected service-account token を Kubernetes API サーバーへ提示し、同じものを外部 IdP とのフェデレーションにも使う。どちらも正規の相手である。しかし双方が同じ Bearer トークンを保有する。aud が二つの用途を許せば、外部 IdP はそのトークンを API サーバーへ提示し、ワークロードになりすませる。

経路上で盗む必要はない。ログの漏えいも、発行者の侵害も要らない。認証先として正当な受信者が、別の受信者にも通用する再利用可能な資格情報を手にすること自体が問題なのである。個々の検証が正しくても、システム全体の境界は失われ得る。

2026 年 9 月 22 日に提出された draft-ietf-wimse-workload-identity-practices-07 が明確にしたのは、この点だ。文書は Informational を予定する現役の Internet-Draft で、Datatracker の状態は AD Evaluation::AD Followup、action holder は Charles Eckel である。承認済みでも RFC でもなく、実装済みや特定事業者の違反を示すものでもない。

SHOULD から MUST へ

改訂 06 も、資格情報を可能な限り狭くし、プラットフォームが複数発行できるならリソースや IdP ごとに別の資格情報を得るべきだとしていた。audience 節では、各 JWT は単一 audience のみを持つべきだと書いていた。

改訂 07 は既定値を変える。資格情報は可能な限り狭い範囲に MUST で制限される。プラットフォーム資源へ直接アクセスする資格情報は、その資源だけを対象に MUST で絞る。フェデレーション用資格情報は IdP を唯一の audience としなければならない。能力例外を除き、JWT は複数 audience を MUST NOT で持ってはならない。

大文字表記だけの違いではない。SHOULD なら事情を踏まえた別案を認めるが、MUST は分離を原則とし、例外側に説明責任を置く。改訂 07 は理由も書き足した。同じ aud に列挙された relying party は、そのトークンを別の relying party に提示し、意図しないアクセスを得る可能性がある。

audience は検証先を選ぶだけの目印ではない。資格情報がどこでワークロードを名乗れるかを表す。受信者を一つ増やすたびに、他の受信者へ再提示できる保有者も一つ増える。

異なる実装モデルに共通する受信者グラフ

Kubernetes は audience と寿命を個別指定した複数の projected token を発行できる。改訂 07 は API サーバー、クラスタ内資源、外部 IdP を分け、それぞれ別トークン、別 audience を要求する。

各地点で aud を検証するだけでは、共有されたグラフは直らない。外部 IdP が issuer、署名、有効期限、audience をすべて正しく検証しても、API サーバーにも通用する資格情報を保持し得る。局所的にすべて成功しながら、全体の分離だけが失敗する。

SPIFFE でも、内部資源向け JWT-SVID と外部 IdP 向け JWT-SVID は別トークン、別 audience でなければならない。クラウドの例では、改訂 06 の SHOULD／SHOULD NOT が、内部アクセスと外部 STS の分離について MUST／MUST NOT へ変わった。製品名ではなく、誰が同じ資格情報を受け取るかが不変の論点である。

例外は能力不足を記録する

プラットフォームによってはワークロードごとに一つの資格情報しか出せず、あるいはワークロード側から audience を制御できない。改訂 07 はその場合に限り、単一 audience の要件を満たせないことを認める。

これは便宜上の抜け道ではない。複数文脈で同じ資格情報を使う構成は、audience による侵害範囲の限定を当てにできない。プラットフォームが許す最短寿命を使い、資格情報へ到達できるコンポーネントを制限し、各受信者を「他の全受信者でワークロードになりすませる主体」として扱う必要がある。

暗号学的な分離が欠ける分、時間、コンポーネント権限、ネットワーク、検証、検知へ負担が移る。補償策は同等性の証明ではない。proof of possession を使えない場合も同様で、短い寿命、厳しい audience、追加のネットワーク制御が SHOULD から MUST になった。寿命を縮めても Bearer トークンが送信者に束縛されるわけではない。

能力例外レシート

運用時点で残すべき最小記録は次の通りだ。

記録項目 残す証拠
発行能力 プラットフォーム、issuer、正確な版、複数資格情報の可否
audience 制御 ワークロードが aud を要求・指定できるか、API または設定証拠
目的 API、内部資源、フェデレーション、外部資源
資格情報の同定 非秘密の一方向指紋または世代。トークン値は保存しない
受信者グラフ 全受理者と受信者間の再提示経路
寿命 要求 TTL、実際の TTL、更新、失効経路
到達範囲 mount、sidecar、proxy、ログ、外向き経路など
検証 各受信者の issuer、audience、type、PoP、ネットワーク条件
例外理由 欠けている能力と分離不能の理由
補償策 短寿命、アクセス制限、ネットワーク、監視、アラート
再審査 責任者、決定時刻、次回審査、修正トリガー、終了条件

指紋は非秘密かつ一方向でなければならない。レシートを理由に Bearer トークンそのものをチケットへ貼ってはならない。目的は、リスク判断を実際の世代、受信者、制御へ結び付けることにある。

「できない」と「しなかった」も区別する。発行者が別資格情報を出せるのに統合側が使い回したなら能力例外ではない。新しい版が audience 制御を備えた時点で終了条件は満たされる。再審査日を持たない例外は、いつの間にか恒久設計になる。

BTW の既報 A Workload Credential Is Not the Workload は、ブートストラップから結果まで八つの証拠を扱った。本稿の問いはより狭い。この Bearer トークンはどの受信者でワークロードを名乗れ、その受信者はどこへ再提示できるのか。

情報源と限界

一次資料は 改訂 07 の Datatracker、文書履歴、固定された改訂 07 本文、比較対象の改訂 06 本文である。調整文書と運用現実を分ける考え方は Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption に沿う。

これらは文書状態、規範文、危険の仕組みを示すが、現実の事故、実装の全数調査、特定運用者の違反を示さない。能力例外レシートは Daniel Kade の編集上の提案であり、WIMSE 草案の必須項目ではない。