OpenAIは、OIDC互換のワークロードIDを短期OpenAIトークンへ交換するWorkload Identity Federationを提供した。対象には主要クラウド、Kubernetes、GitHub Actions、SPIFFEなどが含まれる。

これは「APIキーをVaultへ入れる」改善ではない。長期秘密を配る認証モデルから、実行時にワークロードの身元を証明し、必要な時間だけ権限を得る認証モデルへの変更である。

何が変わったか

従来の一般的な構成では、アプリケーションやCIジョブへOpenAI APIキーを配布し、そのキーを環境変数やシークレットストアから読み出していた。キーはローテーションするまで有効であり、コピー、ログ出力、誤設定、退職者端末、古いCI変数などに残り得る。

Workload Identity Federationでは、ワークロードが所属基盤からOIDC IDトークンを取得し、OpenAIのトークン交換エンドポイントへ提示する。OpenAI側は登録済みのIssuer、Audience、Subjectなどを確認し、対応するService Accountの権限を持つ短期トークンを発行する。

変更前後の差

項目長期APIキーWorkload Identity Federation
認証材料共有可能な秘密文字列署名済みOIDC IDトークン
有効期間ローテーションまで継続短期間
配布CI変数、Secret、設定ファイル実行基盤から都度取得
失効キー削除・ローテーション信頼設定、Service Account、基盤IDの停止
漏えい時の影響残存期間が長いTTLと条件で限定しやすい
監査単位APIキー単位になりやすいワークロード、Subject、Service Account単位

短期化だけで安全になるわけではない。Issuerを広く信頼したり、Subjectの条件が曖昧だったりすると、同じクラウドや同じGitHub組織内の別ワークロードがトークンを取得できる。

誰に影響するか

優先度が高いのは次の環境である。

  • GitHub Actionsや他のCIからOpenAI APIを呼ぶ
  • KubernetesのPodへAPIキーをSecretとして注入する
  • AWS、Azure、Google CloudのサーバーレスやVMでAPIを利用する
  • 複数チームが同じAPIキーを共有している
  • APIキーの棚卸しやローテーションが不完全である
  • 本番・検証・開発の資格情報が混在している
  • 顧客データを扱い、秘密の残存期間を短くしたい

個人のローカル開発を直ちに完全移行する必要はない。ただし本番自動処理とCI/CDでは効果が大きい。

必要な対応

最初に「どのワークロードが、どのOpenAI Projectへ、何の権限で接続するか」を表にする。クラウドアカウントやGitHub Organization全体を一つの信頼境界にしない。

推奨する管理単位は次である。

environment × application × workload-type × privilege

例えば、本番推論API、評価バッチ、デプロイ検証、開発CIを別のService Accountへ分離する。モデル利用、管理API、ファイル操作などの権限も必要最小限にする。

実装・移行手順

1. 既存キーを棚卸しする

利用元、所有者、対象Project、最終利用、保管場所、ローテーション日を記録する。利用元不明のキーを先に無効化してはいけない。ログから呼び出し元を特定する。

2. OpenAI側の信頼設定を作る

OIDC Providerを登録し、Issuer、Audience、許可するSubjectパターンを限定する。ワイルドカードは最小限にする。

GitHub Actionsなら、リポジトリ名だけでなく、ブランチ、Environment、Workflow参照など、実行コンテキストを条件に含める。KubernetesならNamespaceとService Accountを分離する。

3. Service Accountへ対応付ける

OIDC上のアイデンティティをOpenAI Service Accountへマッピングする。人間ユーザーと同じ権限を与えず、用途別に作る。

4. トークン交換を実装する

実行時にIDトークンを取得し、短期OpenAIトークンへ交換する。交換後トークンはメモリ内で保持し、ログ、トレース、エラー本文へ出さない。期限前に再取得するが、無制限の再試行は避ける。

5. 二重運用で検証する

一定期間、WIF経路を主系、既存APIキーを制限付きの退避経路として運用する。成功率、交換失敗、権限不足、レイテンシ、監査ログを確認する。

6. 長期キーを廃止する

WIF経路が安定したら、対象ワークロードのAPIキーを削除する。単に環境変数を消すだけでなく、Secret Manager、CI履歴、テンプレート、Runbook、バックアップからも除去する。

失敗しやすい点

Subject条件が広すぎる

repo:organization/*のような広い条件は、未承認リポジトリからの交換を許す可能性がある。Issuerが正しいだけでは不十分である。

Audienceを検証しない

別用途向けに発行されたIDトークンが再利用される危険がある。OpenAI向けに意図したAudienceを固定する。

Service Accountを共有する

すべてのワークロードを一つのService Accountへ結び付けると、監査と失効の単位が再び粗くなる。

フォールバックキーを恒久化する

障害回避用APIキーが残り続けると、WIF導入後も最大リスクが変わらない。期限付き、保管場所限定、使用時通知を設定する。

時刻ずれとJWKS取得失敗

OIDC検証は時刻と署名鍵取得へ依存する。ノード時刻、DNS、外向き通信、キャッシュを監視する。

評価方法

最低限、次を計測する。

  • トークン交換成功率
  • P50・P95交換レイテンシ
  • Subject不一致による拒否件数
  • Audience不一致件数
  • 期限切れトークン利用件数
  • APIキー利用リクエスト比率
  • Service Account別の利用量
  • 未承認ワークロードからの交換試験結果
  • 失効操作から利用停止までの時間
  • トークンやIDトークンのログ混入件数

本番移行の完了条件は「WIFで呼べる」ではなく、「旧キー利用がゼロで、失効と監査が期待通りに動く」である。

ロールバック

WIF障害時は、対象範囲を限定した短期のBreak-glass APIキーを使う。キーは専用ProjectまたはService Accountへ結び付け、権限と利用上限を抑える。

ロールバック手順には次を含める。

  1. インシデント番号を発行する
  2. Break-glassキーを有効化する
  3. 対象ワークロードだけへ注入する
  4. 使用開始を通知する
  5. WIFのIssuer、JWKS、Audience、Subject、時刻を確認する
  6. 復旧後にキーを削除する
  7. キー利用期間のリクエストを監査する

恒久的な共有APIキーへ戻すことはロールバックではなく、統制の撤回である。

編集部分析

WIFの価値は、秘密を一つ減らすことよりも、認証を「所有物」から「実行時の身元証明」へ変えることにある。これにより、権限、監査、失効をワークロード単位へ細分化できる。

一方、設定ミスの種類は増える。Issuer、Audience、Subject、Service Account、クラウドIAM、OpenAI Projectの対応関係が新しい攻撃面になる。したがって、導入プロジェクトを単なるキー置換として扱わず、信頼関係の設計レビューとして実施すべきである。

最も危険なのは、WIFを導入したという理由でAPIキー管理を終了しながら、古いキーを残す状態である。移行完了の定義には、旧資格情報の発見・削除と、未承認IDの拒否試験を含める必要がある。

実務チェックリスト

  • [ ] 現在のAPIキーと利用元を棚卸しした
  • [ ] 環境・アプリ・用途ごとにService Accountを分離した
  • [ ] Issuer、Audience、Subjectを最小範囲にした
  • [ ] 人間ユーザーの権限をワークロードへ流用していない
  • [ ] 短期トークンをログ・APMへ出さない
  • [ ] 期限切れと再取得を試験した
  • [ ] 未承認リポジトリ・Pod・ブランチからの交換を拒否できた
  • [ ] Break-glassキーに期限と通知を設定した
  • [ ] 旧APIキーをすべての保管場所から削除した
  • [ ] 失効から利用停止までの時間を測定した

一次情報