For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Hauptnavigation

Föderation von Workload-Identitäten für GitHub Actions konfigurieren

Verwende GitHub Actions als Anbieter für Workload-Identitäten, indem du ein von GitHub ausgestelltes OIDC-Token gegen ein kurzlebiges OpenAI-Zugriffstoken austauschst. So können sich Arbeitsabläufe bei der OpenAI API authentifizieren, ohne einen langlebigen API-Schlüssel in GitHub-Secrets zu speichern.

Für Codex kannst du mithilfe dieser Seite das GitHub-Token abrufen und prüfen. Konfiguriere anschließend die Workload-Identität für Codex, um das Token in eine Datei zu schreiben und Codex auf diese Datei zu verweisen. Die Dienstkontozuordnung und die SDK-Beispiele auf dieser Seite gelten für die OpenAI API.

GitHub kann ein signiertes OIDC-JWT für einen Job in einem Ablauf ausstellen, wenn dieser die Berechtigung id-token: write hat und ein Identitätstoken anfordert. OpenAI prüft den Aussteller, die Audience und die Signatur des Tokens sowie die Zuordnungsattribute, bevor ein OpenAI-Zugriffstoken ausgestellt wird.

GitHub Actions einrichten

Erteile dem Ablauf oder Job die Berechtigung, ein GitHub-OIDC-Token anzufordern:

permissions:
  id-token: write
  contents: read

Mit der Berechtigung id-token: write kann der Job ein OIDC-JWT anfordern. Sie gewährt keinen Schreibzugriff auf die Inhalte des Repositorys. Die Berechtigung contents: read wird von actions/checkout benötigt.

Fordere das Token mit genau der Audience an, die in deinem OpenAI-Anbieter für Workload-Identitäten konfiguriert ist. Benutzerdefinierte JavaScript-Aktionen können core.getIDToken("your-wif-audience") aufrufen; Shell-Schritte können die OIDC-Anfrage-URL von GitHub direkt aufrufen. Audience-Werte mit reservierten URL-Zeichen, wie etwa https://api.openai.com/v1, sollten URL-kodiert werden, bevor sie an die Anfrage-URL angehängt werden:

AUDIENCE="https://api.openai.com/v1"
ENCODED_AUDIENCE=$(jq -rn --arg audience "$AUDIENCE" '$audience | @uri')

TOKEN=$(curl -sSf -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
  "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=${ENCODED_AUDIENCE}" | jq -r .value)
export TOKEN

Zu den wichtigen OIDC-Claims von GitHub gehören:

  • iss: Der Aussteller des Tokens. Für GitHub Actions ist dies https://token.actions.githubusercontent.com.
  • aud: Der vom Ablauf angeforderte Audience-Wert. Konfiguriere OpenAI so, dass genau der von dir angeforderte Wert erforderlich ist, zum Beispiel your-wif-audience oder https://api.openai.com/v1.
  • sub: Die zentrale Subject-Zeichenfolge. GitHub setzt sie aus Metadaten des Ablaufs zusammen, etwa Repository, Branch, Tag, Pull Request oder Umgebung.
  • repository: Das Repository, in dem der Ablauf ausgeführt wird, zum Beispiel my-org/my-repo.
  • repository_owner: Die Organisation oder Person, der das Repository gehört, zum Beispiel my-org.
  • ref: Die Git-Referenz, die den Ablauf ausgelöst hat, zum Beispiel refs/heads/main oder refs/tags/v1.0.0.
  • workflow: Der Claim für den Ablauf. Verwende den tatsächlichen Claim-Wert, den GitHub ausgibt, zum Beispiel deploy, wenn dies der Claim für den Ablauf in deinem Job ist.
  • workflow_ref: Der Dateipfad und die Referenz des Ablaufs, zum Beispiel my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main.
  • environment: Der Name der GitHub-Umgebung, zum Beispiel production, wenn der Job eine Umgebung verwendet.
  • run_id, run_number, run_attempt und job_workflow_ref: Kennungen für Ausführungen und Jobs, die bei Audits oder komplexeren Vertrauensregeln hilfreich sein können.

Die vollständige Liste der Claims und die Subject-Formate findest du in der OpenID-Connect-Referenz von GitHub.

Token überprüfen

Bevor du die Föderation von Workload-Identitäten konfigurierst, exportiere das GitHub-OIDC-Token als TOKEN. Führe dann dieses Skript im Runner des Ablaufs aus, um die Claims zu prüfen:

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);

Dieser Befehl dekodiert die JWT-Nutzdaten, ohne die Signatur des Tokens zu überprüfen. Verwende für Tokens aus dem Produktivbetrieb einen lokalen Decoder und füge sie nicht in Tools von Drittanbietern ein. Protokolliere niemals das ursprüngliche GitHub-OIDC-Token oder das durch den Austausch erhaltene OpenAI-Zugriffstoken.

Ein dekodiertes OIDC-Token von GitHub Actions sieht etwa so aus:

{
  "iss": "https://token.actions.githubusercontent.com",
  "aud": "https://api.openai.com/v1",
  "sub": "repo:my-org/my-repo:environment:production",
  "repository": "my-org/my-repo",
  "repository_owner": "my-org",
  "ref": "refs/heads/main",
  "workflow": "deploy",
  "workflow_ref": "my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main",
  "environment": "production",
  "run_id": "1234567890",
  "run_attempt": "1"
}

Vergleiche anhand der dekodierten Nutzdaten das erhaltene Token mit den in OpenAI konfigurierten Werten für Aussteller, Audience und Zuordnung. Die meisten Konfigurationsprobleme lassen sich bereits vor dem Tokenaustausch in den Claims iss, aud, repository, ref und workflow_ref erkennen.

Föderation von Workload-Identitäten einrichten

Erstelle in OpenAI einen Anbieter für Workload-Identitäten für GitHub Actions. Füge anschließend eine Dienstkontozuordnung hinzu, die mit den Claims der GitHub-Arbeitsabläufe übereinstimmt, denen du vertraust.

Konfiguriere zuerst den Anbieter für Workload-Identitäten und erstelle anschließend die Dienstkontozuordnung.

Anbieter für Workload-Identitäten einrichten

  1. Erstelle den Anbieter für Workload-Identitäten. Gib unter Name einen eindeutigen Wert ein, zum Beispiel github-actions-prod. Gib unter Beschreibung etwa Production GitHub Actions workflows ein, damit Admins den Anbieter leichter identifizieren können.

  2. Lege Aussteller und Audience fest. Setze OIDC-Aussteller-URL auf https://token.actions.githubusercontent.com. Setze Audience auf genau die Audience, die dein Ablauf anfordert, zum Beispiel your-wif-audience oder https://api.openai.com/v1.

  3. Verwende die OIDC-Discovery von GitHub. Lass Hochgeladene JWKS zur Tokenüberprüfung verwenden deaktiviert. OpenAI verwendet die OIDC-Discovery-Metadaten und JWKS von GitHub, um das von GitHub signierte Token zu überprüfen.

  4. Füge Attributtransformationen nur hinzu, wenn du abgeleitete Zuordnungsattribute benötigst. Unveränderte GitHub-Claims wie repository, ref und workflow können direkt in Zuordnungsbedingungen verwendet werden. Wenn du abgeleitete Attribute erstellst, fügt das Dashboard automatisch das Präfix openai. hinzu. Gib zum Beispiel github_repository mit dem Ausdruck assertion.repository ein, um openai.github_repository zu erstellen. Unveränderte Token-Claims, die bereits mit openai. beginnen, werden für Zuordnungsschlüssel mit dem Präfix openai. ignoriert, sofern keine passende Transformation konfiguriert ist.

Dienstkontozuordnung einrichten

  1. Erstelle eine Dienstkontozuordnung. Gib unter Name einen Wert ein, der innerhalb des Anbieters für Workload-Identitäten eindeutig ist, zum Beispiel github-actions-main-deploy. Erläutere unter Beschreibung, welcher Ablauf die Zuordnung verwenden kann, zum Beispiel mit Production deploy workflow on main.

  2. Füge Bedingungen für die exakte Übereinstimmung von Claims hinzu. Füge für jeden GitHub-Claim, der übereinstimmen muss, eine Zeile mit Schlüssel und Wert hinzu. OpenAI stellt ein Zugriffstoken nur aus, wenn jede konfigurierte Zeile übereinstimmt. Verwende für einen Ablauf zur Bereitstellung im Produktivbetrieb beispielsweise folgende Bedingungen:

    iss == "https://token.actions.githubusercontent.com"
    aud == "https://api.openai.com/v1"
    repository == "my-org/my-repo"
    ref == "refs/heads/main"
    workflow_ref == "my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main"

    Verwende für Zuordnungen mit erweiterten Berechtigungen vorzugsweise workflow_ref statt workflow, da Admins in der Regel einem bestimmten Dateipfad und einer bestimmten Referenz des Ablaufs vertrauen möchten. Die Namen von Arbeitsabläufen lassen sich ändern, und mehrere Ablaufdateien können denselben Namen haben.

    Trage diese Angaben in der Zuordnungsoberfläche als Schlüssel-Wert-Zeilen ein, zum Beispiel Schlüssel repository mit Wert my-org/my-repo, Schlüssel ref mit Wert refs/heads/main und Schlüssel workflow_ref mit Wert my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main. Wenn der Job eine GitHub-Umgebung verwendet, füge außerdem Schlüssel environment mit Wert production hinzu.

    Achtung: Vermeide zu weit gefasste Zuordnungen, etwa wenn nur repository_owner == "my-org" geprüft wird. Eine solche Zuordnung ist nur sinnvoll, wenn sich jedes Repository in diesem Eigentümer-Namensraum OpenAI-Zugriffstoken ausstellen lassen können soll.

  3. Wähle das Ziel in OpenAI aus. Wähle unter Projekt das OpenAI-Projekt aus, zu dem das gewünschte Dienstkonto gehört. Wähle unter Dienstkonto das OpenAI-Dienstkonto aus, das der GitHub-Ablauf verwenden darf, zum Beispiel github-actions-prod-deploy.

  4. Schränke die API-Berechtigungen bei Bedarf ein. Wähle geeignete Berechtigungen wie api.model.request und api.vector_store.read aus, um den Zugriff durch die mit dieser Zuordnung ausgestellten Tokens weiter einzuschränken. Lass die Berechtigungen leer, wenn du keine WIF-spezifische Einschränkung des Berechtigungsumfangs hinzufügen möchtest. Das Token autorisiert weiterhin den Zugriff als zugeordnetes Dienstkonto.

Token in einem Ablauf verwenden

Konfiguriere deinen Client für das OpenAI SDK so, dass er ein GitHub-OIDC-Token anfordert und gegen ein von OpenAI ausgestelltes Zugriffstoken austauscht.

Der Ablauf muss die Berechtigung id-token: write erteilen und die Einstellungen für die Föderation von Workload-Identitäten an den SDK-Code übergeben. Das SDK fordert das GitHub-OIDC-Token mithilfe der Umgebungsvariablen ACTIONS_ID_TOKEN_REQUEST_URL und ACTIONS_ID_TOKEN_REQUEST_TOKEN an, die GitHub dem Job bereitstellt. Anschließend verwendet es das durch den Austausch erhaltene OpenAI-Zugriffstoken, um API-Anfragen zu authentifizieren.

Du kannst deinen Anwendungscode zum Beispiel in einem Ablauf wie diesem ausführen:

name: deploy

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - name: Run OpenAI SDK code
        env:
          OPENAI_WIF_AUDIENCE: ${{ vars.OPENAI_WIF_AUDIENCE }}
          OPENAI_IDENTITY_PROVIDER_ID: ${{ vars.OPENAI_IDENTITY_PROVIDER_ID }}
          OPENAI_SERVICE_ACCOUNT_ID: ${{ vars.OPENAI_SERVICE_ACCOUNT_ID }}
        run: node ./scripts/call-openai.js

Speichere OPENAI_WIF_AUDIENCE, OPENAI_IDENTITY_PROVIDER_ID und OPENAI_SERVICE_ACCOUNT_ID als Variablen in GitHub Actions. Sie identifizieren den Anbieter und das Dienstkonto, sind aber keine Bearer-Zugangsdaten.

Die folgenden Beispiele initialisieren einen OpenAI-Client mit einem benutzerdefinierten Anbieter für Subject-Tokens. Der Anbieter fordert ein GitHub-OIDC-Token für die konfigurierte Audience an und verwendet es als Subject-Token für die Föderation von Workload-Identitäten.

Mit einem OIDC-Token von GitHub Actions authentifizieren
import OpenAI from "openai";

const identityProviderId = process.env.OPENAI_IDENTITY_PROVIDER_ID;
const serviceAccountId = process.env.OPENAI_SERVICE_ACCOUNT_ID;
const audience = process.env.OPENAI_WIF_AUDIENCE;
const requestURL = process.env.ACTIONS_ID_TOKEN_REQUEST_URL;
const requestToken = process.env.ACTIONS_ID_TOKEN_REQUEST_TOKEN;

if (
  !identityProviderId ||
  !serviceAccountId ||
  !audience ||
  !requestURL ||
  !requestToken
) {
  throw new Error(
    "Set OPENAI_IDENTITY_PROVIDER_ID, OPENAI_SERVICE_ACCOUNT_ID, OPENAI_WIF_AUDIENCE, and run inside GitHub Actions with id-token: write"
  );
}

function githubActionsOIDCTokenProvider(requestURL, requestToken, audience) {
  return {
    tokenType: "jwt",
    getToken: async () => {
      const url = new URL(requestURL);
      url.searchParams.set("audience", audience);

      const response = await fetch(url, {
        headers: { Authorization: `bearer ${requestToken}` },
      });

      if (!response.ok) {
        throw new Error(
          `Failed to request GitHub OIDC token: ${response.status} ${response.statusText}`
        );
      }

      const body = await response.json();
      if (!body.value) {
        throw new Error("GitHub OIDC token response did not include a value.");
      }

      return body.value;
    },
  };
}

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

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

console.log(response.output_text);

Bewährte Methoden für GitHub Actions

  • Verwende Schutzregeln für Umgebungen bei Bereitstellungen im Produktivbetrieb. Verlange Genehmigungen oder Branch-Einschränkungen, bevor Arbeitsabläufe auf OpenAI-Ressourcen im Produktivbetrieb zugreifen können.
  • Beschränke Zuordnungen auf bestimmte Repositorys. Prüfe nach Möglichkeit repositoryspezifische Claims, statt den Zugriff aus allen Repositorys einer Organisation zu erlauben.
  • Beschränke Zuordnungen auf bestimmte Branches oder Arbeitsabläufe. Ziehe in Betracht, Claims wie repository, ref, environment oder workflow_ref auf Übereinstimmung zu prüfen, um die Tokenausstellung einzuschränken.
  • Verwende separate OpenAI-Dienstkonten für CI/CD und Workloads im Produktivbetrieb. Build-Pipelines benötigen häufig andere Berechtigungen als bereitgestellte Anwendungen.
  • Gewähre Pull Requests aus nicht vertrauenswürdigen Forks möglichst keinen Zugriff. Pull Requests aus Forks können Code ausführen, den Angreifende kontrollieren, und sollten keine Zugangsdaten für den Produktivbetrieb erhalten.
  • Nutze den Tokenaustausch für kurzlebige Zugriffstoken. GitHub-OIDC-Tokens sind für die kurzzeitige Authentifizierung vorgesehen und sollten nur bei Bedarf ausgetauscht werden.
  • Überprüfe Änderungen an den Eigentumsverhältnissen von Repositorys. Übertragungen, Umbenennungen und Berechtigungsänderungen bei Repositorys können sich auf die Sicherheitsannahmen auswirken, auf denen bestehende Zuordnungen beruhen.
  • Bevorzuge die exakte Übereinstimmung von Claims. Prüfe Claims wie repository, ref und environment, statt dich auf organisationsweite Vertrauensbeziehungen zu verlassen.