Workload identity federation は「OpenAI API key を配る前提」を崩す

要点

要点まとめ

OpenAI は、CI や Kubernetes に長寿命 API key を置いて配る運用から離れるための案内を出している。
核心は、毎回その workload の身元を確かめたうえで、短時間だけ使える token を渡すことだ。
便利さより重要なのは、どの job なら本番権限を受け取れるかを細かく固定できる点で、ここが secret 配布との違いになる。
仕組みとしては、外部の認証基盤が出す一時的な身分証明を OpenAI 側の短命トークンへ交換し、どの job にどの権限を与えるかを対応付ける。

読解

何が変わったのか

これまで多くの実装では、OpenAI への認証は『API key を安全に置く』問題として扱われてきました。この guide はそうではなく、『外部 workload の身元を毎回検証し、その属性が mapping に一致したときだけ短命 token を出す』問題へ置き換えています。OpenAI の説明でも、trusted workloads が externally issued identity token を short-lived OpenAI access token に交換する形が中心です。

日本の文脈

なぜ重要か

日本の開発現場では、PoC のまま API key を CI や共有 server に載せ続け、そのまま本番化することが多いです。しかし agent 化や自動化が進むほど、漏えい時の被害は『1つのキーが使われた』で終わらず、複数 job、複数 repo、外部委託環境へ広がります。workload identity federation は、この広がりを workload 属性ごとに切るための基盤です。社内審査や顧客監査で『なぜ長寿命 secret を配らなくてよいのか』『どの job にどの権限だけを許すのか』を説明しやすくなる点も大きいです。

技術ポイント

技術的ポイント

Workload identity federation は、外部の OIDC-compatible JWT subject token を OpenAI access token へ交換する方式で、長寿命 API key 保管を前提にしない。
Workload Identity Provider では issuer、`aud`、JWKS 検証方法を定義し、必要なら CEL で `openai.subject` などの derived attribute を作って mapping 判断に使う。
Service account mapping は『どの外部 identity 属性なら、どの OpenAI service account に対して token を mint できるか』を定義する層で、追加 permissions でさらに scope を狭められる。
Wildcard は便利だが、`repo:openai/*` のように prefix 付きでしか使えない。広すぎる pattern は最小権限の考え方を壊しやすい。
JWKS rotation や claim transformation の失敗は、そのまま token exchange failure になる。認証方式を変えるだけで運用負荷が消えるわけではない。

用語

英日キーワード

英語	日本語	補足
workload identity federation	ワークロードIDフェデレーション	外部 workload の身元を使って短命 token を発行する認証方式。長寿命 API key 配布を前提にしない。
OIDC subject token	OIDCサブジェクトトークン	外部 identity provider が発行する JWT。OpenAI 側では workload 属性検証の入力になる。
short-lived access token	短命アクセストークン	OpenAI API 呼び出しに使う有効期限の短い token。漏えい時の持続被害を減らす。
service account mapping	サービスアカウント対応付け	どの属性の workload がどの OpenAI service account を使えるか決める設定。粗い mapping は broad permission の別形になる。
JWKS	JSON Web Key Set	JWT 検証に使う公開鍵集合。rotation 失敗はそのまま token exchange failure になる。
CEL	Common Expression Language	claim から派生属性を作る式言語。federation では mapping 条件を絞るために使う。

試す

試すなら

まず OpenAI を叩いている CI、cron、Kubernetes job を棚卸しし、今どこで長寿命 API key を配っているか書き出す。
issuer、`aud`、`sub`、repo、branch など、mapping に使える claim を確認し、環境や workflow 単位で分けられる最小属性を決める。
service account は用途別に分け、token exchange 後の権限も narrow にする。1つの broad account を全部の job に使い回さない。
本番導入前に、JWKS rotation、claim 不一致、disabled mapping、fork 由来 workflow などの失敗ケースで token が出ないことを確認する。

注意

注意点

OIDC に変えただけで安全になるわけではない。mapping が粗ければ、長寿命 key の代わりに broad token mint 権を配るだけになる。
guide は token exchange の基本を示すが、短命 token の TTL、再取得頻度、監査ログの粒度は別途運用設計が必要。
組織 owner 権限が必要な設定を含むため、個人 project 感覚で気軽に導入できるとは限らない。