OpenAI は API および Codex 自動化のための Workload Identity フェデレーションを追加します

OpenAI は、Workload Identity フェデレーション リソースを公式 SDK に追加し、長期有効な OpenAI 認証情報を保存せずに API および Codex の自動化を認証するためのドキュメントを公開しました。

システムは、サポートされているクラウド、CI、およびワークロード プラットフォームによって発行された ID を受け入れ、それらを有効期限の短い OpenAI アクセス トークンと交換します。 OpenAI には、Amazon Web Services、Microsoft Azure、Google Cloud、Oracle Cloud、Kubernetes、GitHub アクション、SPIFFE 互換環境などのアイデンティティ ソースのサポートが記載されています。

これは SDK の利便性以上のものです。これにより、組織は既存の Workload Identity システムを OpenAI に接続し、API キーの漏洩、コピー、または不適切なローテーションによって引き起こされる損害を制限する方法を得ることができます。また、顧客に代わって自動化されたワークロードを認証するときに、ゲートウェイと開発者プラットフォームが記録する必要がある内容も変更されます。

OpenAI Workload Identity 連携の仕組み

ワークロードは、まずネイティブ環境から資格情報を取得します。プラットフォームと OpenAI サービスに応じて、その ID は OpenID Connect、SPIFFE、または X.509 証明書を通じて表現できます。その後、アプリケーション構成に埋め込まれた永続的な API キーを使用するのではなく、一時的な OpenAI アクセス トークンと交換されます。

OpenAI は、構成を Workload Identity プロバイダーとフェデレーション ルールに分離します。プロバイダーは、どの外部 ID システムが信頼されるかを確立します。フェデレーション ルールは、そのシステムの ID を OpenAI にマッピングする方法を決定します。

OpenAI API ワークロードの場合、外部 ID をプロジェクト サービス アカウントにマッピングできます。マネージド Codex 環境では、OpenAI はワークスペース ユーザーまたはサービス アカウントへのマッピングを文書化します。無人バックエンド プロセスは通常、個々の開発者と同じ ID と権限を継承すべきではないため、この区別は重要です。

11 月 3 日付けの公式 Python およびノー​​ド SDK リリースでは、Workload Identity プロバイダーとフェデレーション ルールを管理するために生成されたリソースが追加されました。ただし、OpenAI は正確な展開範囲を定義する個別の開始記事を公開していません。そのため、組織は移行を計画する前に、アカウントの適格性と構成の可用性を確認する必要があります。

有効期限の短い認証情報が重要な理由

従来の API キーはシンプルですが、運用上の問題が生じます。 CI 変数、コンテナー イメージ、またはデプロイメント スクリプトにコピーされたキーは、誰かがローテーションするか取り消すまで有効なままになる可能性があります。フェデレーションは、その有効な認証情報を、ワークロードがすでに所有し、限られた期間後に期限切れになる ID から派生したアクセス トークンに置き換えます。

実際的な利点は、侵害から免れることではなく、危険にさらされる範囲が狭くなることです。許可された環境内で実行されている悪意のあるプロセスは依然としてトークンを要求し、API を呼び出す可能性があります。したがって、チームには、制限的なフェデレーション ルール、範囲が狭い OpenAI サービス アカウント、外部 ID 発行者に関する制御、および各トークン交換を開始元のワークロードに接続するログが必要です。

GitHub アクションは、当面の使用例の 1 つです。組織は、再利用可能な OpenAI キーをリポジトリまたは組織のシークレットに配置する代わりに、ワークフローの ID を使用できます。クラウドでホストされるサービスと Kubernetes ワークロードは、ネイティブ ID システムを通じて同じ一般的なパターンに従うことができます。

ゲートウェイとパートナー プラットフォームへの影響

フェデレーションでは、開発者チームが使用する AI API コントロール プレーンに新しい認証パスが導入されます。プラットフォームは、すべてのアップストリーム リクエストが静的な顧客キーによって承認されると想定できなくなります。場合によっては、外部ワークロード ID を保持し、有効期限の短いトークンを取得または受け入れ、使用状況を正しい OpenAI プロジェクト サービス アカウントに関連付ける必要があります。

マルチモデル ゲートウェイの場合、この機能は移植性の問題も浮き彫りにします。 ID フェデレーションは、推論リクエストが OpenAI 互換の形式を共有している場合でも、プロバイダー固有です。ベンダー間でこれをサポートするには、個別の信頼構成、トークン交換ロジック、有効期限処理、および障害レポートが必要です。統合エンドポイントは、統合 ID モデルを自動的に作成しません。

同じ問題が AI API 販売代理店プラットフォームにも当てはまります。各顧客のワークロードを範囲が狭いサービス アカウントにマッピングすることは、組織レベルの資格情報を共有するより安全ですが、プラットフォームは、あるテナントの外部 ID が別のテナントの OpenAI プロジェクトに解決されるのを防ぐ必要があります。監査レコードには、外部 ID、フェデレーション ルール、マッピングされた OpenAI プリンシパル、およびその結果として得られる使用属性が保持されている必要があります。

Model Gate および同様のパートナー プラットフォームでは、サポートされているエンタープライズ統合のために顧客が指定したプロバイダー キーの代替としてフェデレーションを評価できます。これを行うには、一時トークンを通常の API キーとして扱うのではなく、明示的なテナントの分離とライフサイクル処理が必要になります。

不明な点

ドキュメントでは認証モデルとサポートされる ID プロバイダーのカテゴリが確立されていますが、導入に関するいくつかの質問はアカウント固有のままです。 OpenAI は、スタンドアロンの発表で、どのプランまたは組織がフェデレーションをすぐに構成できるかを明確に述べていません。 SDK の追加はクライアント サポートを示しますが、SDK タイプ自体は、すべてのアカウントに対応するバックエンド資格があることを確認するものではありません。

注意すべきサービス レベルの違いもあります。OpenAI は、API パスについては X.509 フェデレーションを文書化しますが、Codex パスについては文書化していません。チームは、すべての ID メカニズムが均一に適用されると仮定するのではなく、対象のサービスでサポートされている認証情報の種類を確認する必要があります。

この機能を導入する組織は、既存のキーを削除する前に、トークンの取得、有効期限、失効、およびフォールバックの動作をテストする必要があります。主な利点は、長期間有効な資格情報のフットプリントが小さくなることです。実際のセキュリティは依然として、正確な ID マッピング、制約されたサービス アカウント、および認証、推論、請求を通じてワークロードを追跡する監査証跡に依存しています。