For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション

Google Cloud 向けワークロード ID フェデレーションの構成

次のいずれかのシナリオで、Google Cloud をワークロード ID プロバイダーとして使用します。

  • Google ワークロード ID: アタッチされた Google サービスアカウントに対して発行された Google 署名付き OIDC トークンを、有効期間の短い OpenAI アクセストークンと交換します。
  • Google Kubernetes Engine: 投影された GKE サービスアカウントトークンを、有効期間の短い OpenAI アクセストークンと交換します。

Codex では、このページの手順で Google トークンを取得し、内容を確認します。次に、Codex のワークロード ID を構成し、そのトークンをファイルに書き込んで、Codex の参照先に指定します。このページのサービスアカウントマッピングと SDK の例は、OpenAI API 向けです。

Google ワークロード ID

Google Cloud のワークロードは、有効期間の長いサービスアカウントキーを保存することなく、Google メタデータサーバーから署名付き OIDC ID トークンをリクエストできます。OpenAI のワークロード ID フェデレーションでは、Google ID トークンがサブジェクトトークンとなり、OpenAI はこれを検証してから OpenAI アクセストークンを発行します。このフローは、Compute Engine、Cloud Run、アタッチされた Google サービスアカウントを使用する GKE ワークロード、およびメタデータサーバーの ID エンドポイントを公開するその他の Google 管理ランタイムで利用できます。

Google ワークロード ID のセットアップ

OpenAI API を呼び出す必要があるワークロード用に、Google サービスアカウントを作成します。セットアップ手順の全体については、Google のサービスアカウントの作成ガイドを参照してください。

たとえば、Google Cloud CLI を使用してサービスアカウントを作成します。

gcloud iam service-accounts create openai-wif \
  --description="Service account for OpenAI workload identity federation" \
  --display-name="OpenAI workload identity federation"

サービスアカウントをアタッチした Compute Engine VM を作成するか、アプリケーションを実行している Google Cloud リソースにサービスアカウントをアタッチします。このリソースは、実行時に Google メタデータサーバーを呼び出せる必要があります。VM のセットアップの詳細については、Google のユーザー管理のサービスアカウントを使用する VM の作成ガイドを参照してください。

このフローでは、サービスアカウントキーを作成したり、ダウンロードしたりしないでください。ワークロードは、アタッチされたサービスアカウントとメタデータサーバーを使用して、有効期間の短い OIDC トークンをリクエストします。

Google ID トークンの取得

サービスアカウントをアタッチした Google Cloud リソースから、構成済みのオーディエンスを指定して、メタデータサーバーに OIDC ID トークンをリクエストします。このトークンは、OpenAI が OpenAI 発行のアクセストークンと交換するサブジェクトトークンです。

AUDIENCE="https://api.openai.com/v1"

TOKEN=$(curl -sS -G -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity" \
  --data-urlencode "audience=${AUDIENCE}")
export TOKEN

メタデータサーバーは、Google 署名付き JWT を返します。メタデータサーバーの ID エンドポイントの詳細については、Google のVM の ID の検証ガイドを参照してください。

トークンの検証

ワークロード ID フェデレーションを構成する前に、Google ID トークンを TOKEN としてエクスポートし、次のスクリプトをローカルで実行してクレームを確認します。

const parts = process.env.TOKEN?.split(".") ?? [];
if (parts.length !== 3) {
  throw new Error("Expected a compact JWT with three segments");
}
if (!/^[A-Za-z0-9_-]+$/.test(parts[1]) || parts[1].length % 4 === 1) {
  throw new Error("JWT payload is not valid Base64URL");
}

const bytes = Buffer.from(parts[1], "base64url");
if (bytes.toString("base64url") !== parts[1]) {
  throw new Error("JWT payload is not valid Base64URL");
}
const decoded = new TextDecoder("utf-8", { fatal: true }).decode(bytes);
const claims = JSON.parse(decoded);
if (claims === null || Array.isArray(claims) || typeof claims !== "object") {
  throw new Error("JWT payload is not a JSON object");
}
console.log(decoded);

このコマンドは、トークンの署名を検証せずに JWT ペイロードをデコードします。本番環境のトークンにはローカルのデコーダーを使用し、サードパーティのツールに貼り付けないようにしてください。

Google メタデータサーバーの ID トークンをデコードすると、次のようになります。

{
  "iss": "https://accounts.google.com",
  "aud": "https://api.openai.com/v1",
  "azp": "110123456789012345678",
  "sub": "110123456789012345678",
  "email": "openai-wif@my-project.iam.gserviceaccount.com",
  "email_verified": true,
  "iat": 1716235422,
  "exp": 1716239022
}

デコードしたペイロードを使用して、受け取ったトークンと、OpenAI で構成した発行者、オーディエンス、マッピング値を比較します。構成に関する問題の多くは、トークンを交換する前に issaudemailsub の各クレームで確認できます。

ワークロード ID フェデレーションのセットアップ

Google 発行の ID トークン用に OpenAI でワークロード ID プロバイダーを作成し、トークン内の変化しにくいクレームと照合するサービスアカウントマッピングを追加します。

まずワークロード ID プロバイダーを構成し、その後サービスアカウントマッピングを作成します。

ワークロード ID プロバイダーのセットアップ

  1. ワークロード ID プロバイダーを作成します。 名前 には、google-workload-identity-prod などの一意の値を設定します。管理者がプロバイダーを識別しやすいように、 説明には Production Google Cloud workloads などを入力します。

  2. 発行者とオーディエンスを設定します。 OIDC 発行者 URLhttps://accounts.google.com に設定します。 オーディエンス には、https://api.openai.com/v1 など、ワークロードが Google メタデータサーバーへのリクエストで指定するカスタムオーディエンスを設定します。この値は、トークンの aud クレームと一致する必要があります。

  3. Google の OIDC ディスカバリを使用します。 アップロードした JWKS をトークンの検証に使用 は無効のままにします。OpenAI は、Google の OIDC ディスカバリメタデータと JWKS を使用して、Google 署名付き ID トークンを検証します。

  4. マッピング用の派生属性が必要な場合は、属性変換を追加します。 たとえば、subject と式 assertion.sub を入力すると、サブジェクトクレームから openai.subject を作成できます。ダッシュボードは openai. プレフィックスを自動的に付加します。元のトークンのクレームがすでに openai. で始まる場合、対応する変換が構成されていない限り、openai. マッピングキーではそのクレームが無視されます。

サービスアカウントマッピングのセットアップ

  1. サービスアカウントマッピングを作成します。 名前 には、compute-openai-wif など、ワークロード ID プロバイダー内で一意の値を設定します。 説明には Production Compute Engine OpenAI API workload などを入力し、このマッピングを使用できるワークロードを説明します。

  2. Google サービスアカウントの変化しにくいクレームを照合します。 一致が必要なクレームごとに、 キー の行を 1 つ追加します。sub は変化しにくく一意であるため、ID の主要な紐付けに使用します。読みやすくするために、email も照合条件に追加できます。

  3. OpenAI 側の対象を選択します。 プロジェクト には、対象のサービスアカウントが属する OpenAI プロジェクトを設定します。 サービスアカウント には、google-workload-identity-prod-openai-wif など、Google Cloud ワークロードが使用できる OpenAI サービスアカウントを設定します。

  4. 必要に応じて API 権限を絞り込みます。 api.model.requestapi.vector_store.read などの適切な 権限 を選択し、このマッピングから発行されるアクセストークンの権限をさらに絞り込みます。WIF 固有のスコープ制限を追加しない場合は、権限を空欄のままにします。その場合も、トークンはマッピング先のサービスアカウントとして認可されます。

コードでのトークンの使用

メタデータサーバーに Google ID トークンをリクエストし、OpenAI 発行のアクセストークンと交換するように、OpenAI SDK クライアントを構成します。

OPENAI_WIF_AUDIENCE には、ワークロード ID プロバイダーのオーディエンスとして構成したカスタムオーディエンスを設定します。SDK は、そのオーディエンス用の Google ID トークンをリクエストし、OpenAI 発行のアクセストークンと交換して、その OpenAI トークンを API リクエストの認証に使用します。

Google メタデータサーバーの ID トークンによる認証
import OpenAI from "openai";

const metadataEndpoint =
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity";

const identityProviderId = process.env.OPENAI_IDENTITY_PROVIDER_ID;
const serviceAccountId = process.env.OPENAI_SERVICE_ACCOUNT_ID;
const audience = process.env.OPENAI_WIF_AUDIENCE;

if (!identityProviderId || !serviceAccountId || !audience) {
  throw new Error(
    "Set OPENAI_IDENTITY_PROVIDER_ID, OPENAI_SERVICE_ACCOUNT_ID, and OPENAI_WIF_AUDIENCE"
  );
}

function googleMetadataIdentityTokenProvider(audience) {
  return {
    tokenType: "jwt",
    getToken: async () => {
      const url = new URL(metadataEndpoint);
      url.searchParams.set("audience", audience);
      url.searchParams.set("format", "full");

      const response = await fetch(url, {
        headers: { "Metadata-Flavor": "Google" },
      });

      if (!response.ok) {
        throw new Error(
          `Google metadata token request failed with status ${response.status}.`
        );
      }

      const token = (await response.text()).trim();
      if (!token) {
        throw new Error(
          "Google metadata server did not return an identity token."
        );
      }

      return token;
    },
  };
}

const client = new OpenAI({
  workloadIdentity: {
    identityProviderId,
    serviceAccountId,
    provider: googleMetadataIdentityTokenProvider(audience),
  },
});

const response = await client.responses.create({
  model: "gpt-5.6-terra",
  input: "Say hello from Google Cloud workload identity federation.",
});

console.log(response.output_text);

Google Cloud のベストプラクティス

  • ワークロードごとに専用の Google サービスアカウントを使用します。無関係なサービスや環境の間でサービスアカウントを共有することは避けてください。
  • 有効期間の長いサービスアカウントキーの代わりに、ワークロード ID のフローを使用します。メタデータサーバーの ID トークンや GKE ワークロード ID を使用できるワークロードでは、JSON キーファイルの配布やローテーションを避けてください。
  • ID の適用範囲は、実用上可能な最小単位のワークロードに限定します。アプリケーションごとにサービスアカウントを分けると、監査対象が明確になり、最小権限でのアクセスを実現できます。
  • 属性ベースのマッピングは慎重に使用します。可能な限り、変更可能なメタデータよりも、サービスアカウントのサブジェクトクレームなどの安定した識別子を優先してください。
  • 本番環境と非本番環境のプロジェクトを分離します。プロジェクトを分けることで、意図せず権限を共有するリスクを減らし、監査を簡素化できます。
  • 必要な IAM 権限のみを付与します。Google ID の権限は、ワークロードに必要なものだけに制限してください。
  • サービスアカウントの使用状況を監視します。予期しないトークン交換は、設定のドリフトやワークロードの侵害を示している可能性があります。