API-Schlüssel raus aus CI: Workload Identity statt Dauerschlüssel

Ein Secret ist kein Identitätskonzept

Am 8. Oktober 2026 wurden Mutual TLS und X.509 Workload Identity Federation für die OpenAI API allgemein verfügbar. Das ist mehr als eine neue Login-Option. Es ist ein guter Anlass, eine der bequemsten und zugleich riskantesten Gewohnheiten moderner Produktteams zu beenden: einen langlebigen API-Schlüssel in CI, Serverless-Plattform und Produktionsserver zu kopieren und ihn dort jahrelang als Identität zu behandeln.

Ein API-Schlüssel beantwortet im Wesentlichen nur: Wer besitzt dieses Geheimnis? Er erklärt nicht zuverlässig, welcher konkrete Workflow läuft, aus welchem Repository er kommt, in welcher Umgebung er arbeitet oder wie lange diese Berechtigung gelten soll. Wird der Schlüssel kopiert, ist die Kopie genauso mächtig wie das Original. Wird er geleakt, endet sein Leben erst mit einer aktiven Rotation.

Workload Identity dreht dieses Modell um. Eine Maschine weist mit ihrer bereits vorhandenen Identität nach, wer sie ist. OpenAI prüft diesen Nachweis, ordnet ihn einem Service Account zu und stellt ein kurzlebiges Zugriffstoken aus. Der produktive Prozess braucht keinen dauerhaft gespeicherten OpenAI API Key mehr.

Drei Dinge, die häufig verwechselt werden

Bevor ein Team migriert, müssen drei Ebenen auseinandergehalten werden:

• Workload Identity Federation tauscht einen verifizierten externen Nachweis gegen ein kurzlebiges OpenAI Access Token.
• Mutual TLS verlangt zusätzlich zum Bearer Credential ein akzeptiertes Client-Zertifikat auf der TLS-Verbindung.
• Service Accounts und ihre Rollen bestimmen, was die gemappte Workload im gewählten Projekt tatsächlich darf.

Keine dieser Ebenen ersetzt automatisch die anderen. Bei X.509 Workload Identity wird der API-Schlüssel durch ein kurzlebiges Access Token ersetzt, nicht aber das Client-Zertifikat. Beim späteren API-Aufruf werden Bearer Token und akzeptiertes Zertifikat unabhängig geprüft. Ein Zertifikat allein autorisiert keinen API-Aufruf.

Auch reines mTLS ist nicht automatisch Workload Identity. Es ergänzt die normale Authentifizierung um Zertifikatsprüfung. Eine Anwendung kann mTLS weiterhin mit einem API Key verwenden. Der eigentliche Sicherheitsgewinn der Federation entsteht erst, wenn der langlebige OpenAI-Schlüssel verschwindet und eine begrenzte Maschinenidentität an seine Stelle tritt.

Für CI ist OIDC meistens der erste Schritt

GitHub Actions kann für einen einzelnen Job ein signiertes OIDC-Token ausstellen. OpenAI validiert unter anderem Herausgeber, Zielgruppe, Signatur und die konfigurierten Mapping-Attribute und gibt anschließend ein kurzlebiges Access Token zurück. Der Workflow benötigt dafür id-token: write; diese Berechtigung erlaubt das Anfordern des Identitätstokens, aber keinen Schreibzugriff auf Repository-Inhalte.

Das Zielbild für eine Pipeline sieht so aus:

1. Der Job startet in einem bekannten Repository und einer bekannten Umgebung.
2. GitHub stellt ein kurzlebiges OIDC-Token für eine exakt konfigurierte Audience aus.
3. Eine OpenAI Identity-Provider-Regel akzeptiert nur die beabsichtigten Claims.
4. Das Mapping verweist auf einen dedizierten Service Account im richtigen Projekt.
5. OpenAI stellt ein kurzlebiges Access Token aus.
6. Der Job verwendet dieses Token und verwirft es mit dem Runner.

Provider-ID, Service-Account-ID und Audience können als normale CI-Variablen gespeichert werden; sie sind keine Bearer Credentials. Entscheidend ist, die Mapping-Regel eng zu halten. „Jeder Job aus dieser Organisation“ ist bequem, schafft aber wieder eine große gemeinsame Vertrauenszone. Repository, Branch oder Environment sollten nur so breit gematcht werden, wie der reale Prozess es verlangt.

X.509 ist stark, wenn die Workload bereits Zertifikate beherrscht

Nicht jede Umgebung stellt brauchbare OIDC-Tokens aus. Manche Unternehmen betreiben bereits eine eigene PKI, Hardware-geschützte Schlüssel oder Zertifikate für Maschinenidentitäten. Dort kann X.509 Workload Identity gut passen.

Der Ablauf besteht aus fünf Teilen:

1. Eine vertrauenswürdige Root-CA wird in den Mutual-TLS-Einstellungen hinterlegt und aktiviert.
2. Der Identity Provider leitet aus dem geprüften Client-Zertifikat Attribute ab, darunter einen nicht leeren openai.subject.
3. Ein Mapping verbindet diese Identität mit genau einem OpenAI Service Account.
4. Die Workload präsentiert ihr Zertifikat am X.509 Token Endpoint und erhält ein kurzlebiges Bearer Token.
5. Für den API-Aufruf sendet sie das Bearer Token plus ein akzeptiertes Client-Zertifikat an den mTLS API Host.

Das Token lebt höchstens eine Stunde und niemals länger als das geprüfte Client-Zertifikat. Es gibt kein Refresh Token; die Anwendung führt den Austausch rechtzeitig erneut durch. Die offiziellen SDKs können Zertifikat, Token-Austausch, mTLS Host und Erneuerung übernehmen.

Wichtig ist die ehrliche Grenze: Auch dieses Modell besitzt einen privaten Schlüssel. Er gehört nicht in Git, Logs oder ein gemeinsam genutztes CI-Secret. Er muss so geschützt werden, dass nur die beabsichtigte Workload darauf zugreifen kann. Federation beseitigt nicht jede geheime Information — sie verkleinert Lebensdauer, Reichweite und Wiederverwendbarkeit des eigentlichen API-Zugriffs.

Eine Identität pro Produktgrenze

Der häufigste Architekturfehler ist ein einziger „AI Production“-Service-Account für Website, Supportbot, Datenpipeline und interne Tools. Dann kann zwar der API Key verschwinden, aber der Blast Radius bleibt fast unverändert.

Sinnvoller ist eine Identität entlang echter Produkt- und Umgebungsgrenzen:

• Support-Zusammenfassungen in Produktion;
• Content-Vorbereitung in Staging;
• Evaluationen in CI;
• interne Analysejobs;
• interaktive Entwicklerumgebungen.

Jede Workload erhält ein eigenes Mapping und einen Service Account mit den benötigten Projektrollen. So lässt sich ein kompromittierter Workflow deaktivieren, ohne alle anderen Anwendungen anzuhalten. Kosten, Fehlerraten und Audit-Spuren werden ebenfalls verständlicher, weil eine Identität einen konkreten Zweck besitzt.

Menschliche Nutzung gehört nicht in dasselbe Mapping. Ein Entwickler-Laptop, ein CI-Job und ein Produktionsdienst haben unterschiedliche Lebenszyklen, Risiken und Recovery-Wege. Wer sie unter einer gemeinsamen Identität zusammenfasst, verliert genau die Trennung, die Workload Identity schaffen soll.

Claims sind eine Firewall, kein Namensschild

Ein Federation Provider beweist nur, dass ein Token von einem vertrauenswürdigen Herausgeber stammt. Erst die Attributbedingungen und das Mapping entscheiden, welche der vielen dort existierenden Identitäten akzeptiert werden.

Für GitHub Actions sollte das Team mindestens prüfen:

• exakte Audience;
• Repository Owner und Repository;
• Branch, Tag oder geschütztes Environment;
• Workflow-Datei oder Job-Kontext, wenn für die Grenze relevant;
• erwarteter Token-Herausgeber und kurze Laufzeit.

Für X.509 gehören Subject, SANs, ausstellende Kette und gegebenenfalls CEL-Filter in dieselbe Bedrohungsanalyse. Eine breite Wildcard spart Konfiguration, verwandelt aber einen gezielten Zugang in einen Generalschlüssel.

Die Regel sollte lesbar dokumentieren, welche reale Maschine oder Pipeline eintreten darf. Eine technische Bedingung, die niemand mit dem Deployment-Prozess verbinden kann, wird bei der nächsten Änderung entweder zu weit geöffnet oder versehentlich gebrochen.

Rotation ohne „Big Bang“

Zertifikatsrotation darf kein Wartungsfenster erzwingen. OpenAI empfiehlt für Trust Anchors eine Überlappung:

1. neue Root oder neuen Trust Anchor hochladen, ohne den alten zu deaktivieren;
2. den neuen Anchor zuerst in einem unkritischen Projekt aktivieren;
3. Workloads auf Zertifikate der neuen Kette umstellen und alle verwendeten Hosts sowie API-Pfade testen;
4. den alten Anchor erst nach vollständiger Migration deaktivieren;
5. ihn erst danach löschen.

Zwischenzertifikate lassen sich rotieren, ohne die Root zu ersetzen. Die Workload muss beim TLS-Handshake aber die vollständige aktuelle Kette präsentieren; OpenAI lädt fehlende Intermediates nicht aus Zertifikats-URLs nach.

Für OIDC liegt der Schwerpunkt auf Signing Keys, Audience und Provider-Konfiguration. Alte und neue öffentliche Schlüssel sollten während der Umstellung gleichzeitig validierbar sein. Der Token-Austausch muss außerdem mit Uhrabweichungen und temporären Fehlern umgehen, ohne abgelaufene Tokens endlos weiterzuverwenden.

Der Rollout braucht einen Rückweg

mTLS-Aktivierung verändert das Anfrageverhalten. Deshalb beginnt sie nicht organisationsweit. Die offizielle Anleitung empfiehlt ein unkritisches Projekt und einen getesteten Recovery-Pfad.

Ein belastbarer Rollout enthält:

• einen kleinen Smoke-Test über denselben SDK- und Netzwerkpfad wie Produktion;
• Tests für jeden regionalen mTLS Host, der wirklich verwendet wird;
• einen Alarm für fehlgeschlagene Token Exchanges und Zertifikatsfehler;
• einen dokumentierten Owner für Provider, Mapping, Service Account und Trust Anchor;
• einen zeitlich begrenzten Fallback, der nicht zur Dauerlösung wird;
• eine Übung für Deaktivierung und erneute Aktivierung.

Bei X.509 liefern Fehler absichtlich keine detaillierte Auskunft über Root, Provider oder Mapping. Monitoring muss daher die eigenen Schritte sichtbar machen: Zertifikatsablauf, erfolgreiche Exchanges, Token-Ablaufzeit, verwendeter Service Account und Zielhost — ohne private Schlüssel, Zertifikatsinhalte oder Access Tokens zu loggen.

Was sich nicht automatisch löst

Kurzlebige Tokens sind kein Freifahrtschein. Die X.509-Dokumentation nennt wichtige Grenzen:

• Das Bearer Token ist nicht kryptografisch an ein bestimmtes Zertifikat gebunden.
• Es gibt weder DPoP noch einen cnf Claim.
• Zertifikats-Revocation über CRL oder OCSP wird in diesem Flow nicht geprüft.
• Fehlende Intermediate-Zertifikate werden nicht automatisch bezogen.
• Codex unterstützt X.509 Federation nicht; dafür sind OIDC oder SPIFFE JWT-SVID vorgesehen.

Incident Response muss deshalb Root-Aktivierung, Provider, Mapping, Service Account und die kurze Token-Laufzeit gemeinsam betrachten. Ein gestohlener kurzlebiger Token bleibt bis zu seinem Ablauf sensibel. Ein kompromittierter Zertifikatsschlüssel verlangt eine schnelle Deaktivierung der betroffenen Vertrauenskette oder Mapping-Regel.

Ein pragmatischer Migrationsplan

Wir würden nicht alle Secrets auf einmal ersetzen. Der kleinste sinnvolle Weg sieht so aus:

1. Alle Stellen inventarisieren, an denen OpenAI API Keys gespeichert, kopiert oder zur Laufzeit geladen werden.
2. Eine klar begrenzte, nicht kritische Workload wählen.
3. Einen eigenen Service Account und ein enges Identity Mapping anlegen.
4. OIDC bevorzugen, wenn die Plattform bereits verifizierbare Workload-Tokens ausstellt; X.509 wählen, wenn eine belastbare Zertifikatsidentität vorhanden ist.
5. Token-Austausch, Erneuerung, Fehler und Audit-Signale implementieren.
6. Parallelbetrieb nur für eine definierte Frist erlauben.
7. Den alten API Key widerrufen und prüfen, dass kein Fallback ihn heimlich weiterverwendet.
8. Das Muster erst danach auf weitere Workloads übertragen.

Das Ziel ist nicht „keine Secrets mehr“. Das Ziel ist, dass eine Maschine ihre Identität beweist, nur die passende Rolle erhält und der daraus entstehende Zugriff von selbst verfällt. Ein verlorener Dauerschlüssel wird so von einem stillen, offenen Risiko zu einem begrenzten und beobachtbaren Sicherheitsereignis.

Quellen

• OpenAI API Changelog: mTLS und X.509 Workload Identity GA
• OpenAI: Workload Identity Federation
• OpenAI: X.509 Workload Identity konfigurieren
• OpenAI: Mutual TLS
• OpenAI: GitHub Actions mit Workload Identity Federation