Schlüssellose Upstream-Authentifizierung für AI API Gateways: Ein Workload Identity Federation-Muster
Ersetzen Sie langlebige Anbieterschlüssel durch Workload-Identität und kurzlebige Token, ohne Aktualisierungsausfälle zu verursachen, Identitätszuordnungen zu schwächen oder stillschweigend auf gemeinsame Anmeldeinformationen zurückzugreifen.
Produktions-Gateway-Worker sollten keine langlebigen Upstream-API-Schlüssel tragen, wenn der Anbieter die Arbeitslast selbst authentifizieren kann. Das sicherere Muster besteht darin, eine vorhandene Cloud-, Kubernetes-, CI- oder SPIFFE-Identität gegen kurzlebige Anbieteranmeldeinformationen auszutauschen, diese Anmeldeinformationen korrekt zwischenzuspeichern und auf die kleinste nützliche Autorisierungsgrenze zu beschränken.
Der schwierige Teil ist nicht der Token-Austausch. Es bewältigt ungleichmäßige Anbieterunterstützung, gleichzeitige Aktualisierungen, Identitätszuordnung, Ausnahmen auf der Steuerungsebene, Ausfälle und Migration, ohne einen versteckten Fallback auf einen allgemein privilegierten gemeinsamen Schlüssel zu schaffen.
Beginnen Sie mit Authentifizierungsfunktionen, nicht mit einer globalen schlüssellosen Einstellung
Fakt: Die Authentifizierungsunterstützung unterscheidet sich je nach Anbieter und Vorgang. OpenAI und Anthropic unterstützen die Workload Identity-Föderation für API Arbeitslasten. Azure OpenAI unterstützt Microsoft Entra ID und verwaltete Identitäten. Google Cloud unterstützt angehängte Dienstkonten, Standardanmeldeinformationen für Anwendungen und Workload Identity Federation für externe Arbeitslasten. Laufzeitinferenz- und Verwaltungs-APIs akzeptieren jedoch nicht unbedingt dieselben Anmeldeinformationstypen.
Zum Beispiel können OpenAI Workload Identity-Tokens derzeit keine Admin-Endpunkte API aufrufen. Ein Gateway kann die Authentifizierung daher nicht sicher als ein Feld auf Anbieterebene wie auth_mode: federated.
Empfehlung: Erstellen Sie eine Funktionsmatrix, die nach Anbieterkonto, Endpunktfamilie, Umgebung und Betriebsklasse verschlüsselt ist:
| Anbieterkonto | Vorgang | Bevorzugte Authentifizierung | Zulässige Ausnahme |
|---|---|---|---|
| Anbieter A-Produktion | Laufzeit Inferenz | OIDC-Austausch | Keine während des normalen Betriebs |
| Anbieter A Produktion | Organisationsverwaltung | Administratorberechtigung | Isolierte Steuerungsebene worker |
| Azure-Bereitstellung | Laufzeitinferenz | Verwaltete Identität | Genehmigtes Break-Glass-Verfahren |
| Vertex AI-Projekt | Laufzeit inference | Standardanmeldeinformationen der Anwendung | Externe Workload-Föderation |
Speichern Sie diese Matrix als versionierte Konfiguration. Die Routenzulassung sollte einen Vorgang ablehnen, wenn seine konfigurierte Identität die erforderliche Authentifizierungsfähigkeit nicht erfüllen kann. Dies gehört in eine KI API Kontrollebene für Entwicklerteams, nicht in undokumentierte Umgebungsvariablen für einzelne Arbeiter.
Setzen Sie einen Anmeldeinformationsbroker zwischen Routing- und Provider-Adaptern ein.
Anbieteradapter sollten keine Metadatenanmeldeinformationen abrufen, keine Assertionen erstellen oder die Tokenaktualisierung unabhängig verwalten. Führen Sie einen Anmeldeinformationsbroker mit einer schmalen Schnittstelle ein:
Credential acquire(CredentialRequest request)
CredentialRequest {
provider_account_id
workload_identity_id
operation_class
target_service_account
audience
scopes
}
Credential {
value
expires_at
authorization_context
provenance
}
Der Anmeldeinformationswert ist vertraulich und muss im Speicher oder in einem genehmigten flüchtigen Cache verbleiben. Der Autorisierungskontext zeichnet das Anbieterprojekt, das Dienstkonto, die Bereiche, Rollen oder Bereitstellungseinschränkungen auf, die durch das Token dargestellt werden. Die Herkunft gibt an, wie es erworben wurde, z. B. oidc_exchange, managed_identity, adc oder break_glass.
Dieser Vertrag bleibt beim Routing anbieterneutral und behält gleichzeitig die für Autorisierungsprüfungen und Telemetrie erforderlichen Details bei. Es verhindert außerdem, dass ein Multimodell-APIGateway für Teams jedes Inhaber-Token als austauschbar behandelt.
Verwenden Sie anbieterspezifische Akquisitionsadapter
Jeder Erfassungsadapter sollte nur die von seinem Anbieter geforderten Schritte ausführen:
- Erhalten Sie eine externe Behauptung von der lokalen Identitätsquelle, z. B. ein projiziertes Kubernetes-Dienstkonto-Token, einen Cloud-Metadatendienst oder eine SPIFFE-Arbeitslast API.
- Fordern Sie die genaue Zielgruppe an, die vom Anbieter oder der konfigurierten Föderationsregel erwartet wird.
- Tauschen Sie die Behauptung aus, wenn der Anbieter ein Token benötigt Exchange.
- Gibt die resultierenden Anmeldeinformationen und die maßgebliche Ablaufzeit zurück.
- Klassifizieren Sie Fehler als lokale Identitäts-, Austausch-, Autorisierungs-, Konfigurations- oder Anbieterverfügbarkeitsfehler.
Der OpenAI-kompatible Endpunkt von Vertex AI ist ein nützliches Beispiel für Trennung: Eine Anwendung kann über die Standardanmeldeinformationen der Anwendung ein Google-Zugriffstoken erhalten und dieses Token als Anmeldeinformationen des OpenAI-Clients bereitstellen. Der Protokolladapter bleibt OpenAI-kompatibel, während die Erfassung von Anmeldeinformationen Google-spezifisch bleibt.
Machen Sie den Token-Cache autorisierungsorientiert
Fakt: Föderierte Anmeldeinformationen sind nur von kurzer Dauer. OpenAI Workload Identity-Zugriffstokens dauern nicht länger als eine Stunde, können das externe Betreff-Token oder das verifizierte Zertifikat nicht überleben und werden ohne Aktualisierungstokens ausgestellt. Die Arbeitslast muss den Austausch vor Ablauf wiederholen.
Ein Cache-Schlüssel muss jede Dimension enthalten, die die resultierende Autorität ändern kann:
cache_key = hash(
provider_account_id,
workload_identity_id,
target_service_account,
audience,
normalized_scopes,
operation_class
)
Das Weglassen des Zielkontos, der Zielgruppe oder der Zielbereiche kann dazu führen, dass ein Worker ein gültiges Token im falschen Autorisierungskontext wiederverwendet. Das ist gefährlicher als ein Cache-Miss.
Aktualisieren Sie vor Ablauf mit einer Sicherheitsmarge und zufälligem Jitter. Eine praktische Richtlinie ist:
refresh_at = expires_at
- max(configured_margin, token_lifetime * 0.10)
- random_jitter
Der genaue Spielraum sollte Taktabweichung, Austauschlatenz, Wiederholungszeit und die längste erwartete Anfrage berücksichtigen. Aktualisieren Sie nicht ausschließlich nach einem festen Timer, der von expires_at.
Verhindern Sie Exchange-Stürme mit der Aktualisierung einzelner Flüge
Wenn viele Anfragen auf dasselbe bald abgelaufene Token stoßen, sollte nur eine Ausführung den Austausch durchführen. Andere Anrufer sollten weiterhin die vorhandenen Anmeldeinformationen verwenden, solange diese innerhalb des zulässigen Fensters bleiben, oder kurz auf das gemeinsame Aktualisierungsergebnis warten.
Verwenden Sie eine Single-Flight-Sperre pro Cache-Schlüssel. Entscheiden Sie bei einer Bereitstellung mit mehreren Prozessen oder mehreren Knoten, ob jeder Worker seinen eigenen Cache verwalten darf oder ob die Aktualisierungskoordination verteilt werden muss. Ein lokaler Cache ist einfacher, erhöht jedoch das Austauschvolumen. Ein verteilter Cache reduziert den Austausch, erweitert jedoch die Grenze zwischen sensiblen Token und erfordert einen verschlüsselten Transport, eine strenge Zugriffskontrolle und eine sorgfältige Räumung.
Empfehlung: Bevorzugen Sie In-Process-Caches, es sei denn, Anbieterbeschränkungen oder Flottengröße belegen die Notwendigkeit eines Shared-Token-Dienstes. Koordinieren Sie zunächst die Aktualisierungen innerhalb jedes Prozesses und messen Sie dann das Austauschvolumen.
Identitäten an genaue Workload-Ansprüche binden
Föderation verschiebt Vertrauen von einem gespeicherten Schlüssel auf Identitätsansprüche. Eine freizügige Zuordnung kann daher genauso gefährlich sein wie ein durchgesickerter gemeinsamer Berechtigungsnachweis.
Validieren Sie den Aussteller und die beabsichtigte Zielgruppe und binden Sie dann die Zuordnung an unveränderliche oder streng kontrollierte Ansprüche. Schließen Sie für Kubernetes den Namespace und das Dienstkonto ein, anstatt einer Arbeitslast im Cluster zu vertrauen. Beschränken Sie für CI das Repository, den Workflow, die Umgebung und den geschützten Zweig- oder Bereitstellungskontext. Ordnen Sie für Cloud-Identitäten einen bestimmten Arbeitslastprinzipal zu und nicht einen gesamten Mandanten oder eine gesamte Organisation.
Erstellen Sie separate Upstream-Dienstkonten oder verwaltete Identitäten für Produktion, Staging, Hintergrundjobs und Verwaltungsautomatisierung. Beschränken Sie jede Identität auf die Modelle, Projekte, Arbeitsbereiche, Bereitstellungen und API Vorgänge, die sie benötigt.
Fakt: OpenAI kann Workload-Identitätszuordnungen mit API Berechtigungen einschränken. Anthropic verknüpft ausgetauschte Anmeldeinformationen mit einem Dienstkonto und warnt, dass die Föderation nur so sicher ist wie die Upstream-Identitätskonfiguration. Verwaltete Identitäten und Cloud IAM hängen ebenfalls von Rollenzuweisungen mit korrektem Umfang ab.
Laufzeitanmeldeinformationen von Administratoranmeldeinformationen trennen
Ein Inferenzarbeiter sollte niemals ein Organisationsadministrator-Token erben, nur weil eine Aufgabe auf der Steuerungsebene noch eines benötigt. Teilen Sie das System in zwei Sicherheitsgrenzen auf:
- Laufzeitebene: Verarbeitet Modellanfragen und empfängt nur föderierte oder verwaltete Anmeldeinformationen mit Rückschlussbereich.
- Steuerungsebene: Führt Projekt-, Arbeitsbereichs-, Abrechnungs- oder Dienstkontoverwaltung über isolierte Jobs mit separat gespeicherten Anmeldeinformationen und strengeren Genehmigungskontrollen durch.
Administratoranmeldeinformationen sollten keinen Pfad zu Laufzeitumgebungsvariablen, Pod-Spezifikationen, Debug-Bundles oder Token-Caches haben. Zeichnen Sie ihre Verwendung im selben reinen Append-Audit-System auf, das für Konfigurationsänderungen verwendet wird.
Fehler behoben, ohne dass die Wiederherstellung improvisiert wurde
Empfehlung: Ersetzen Sie einen fehlgeschlagenen Verbundaustausch nicht automatisch durch einen gemeinsam genutzten statischen Schlüssel. Automatisches Fallback kann eine widerrufene Zuordnung umgehen, eine falsche Zielgruppe verbergen oder den Zugriff wiederherstellen, den ein Identitätsadministrator absichtlich entfernt hat.
Geben Sie einen klassifizierten Upstream-Authentifizierungsfehler zurück, stoppen Sie die Weiterleitung an das betroffene Anbieterkonto und erlauben Sie der normalen Routing-Richtlinie, nur dann einen anderen Anbieter auszuwählen, wenn diese Alternative für den Mandanten und die Arbeitslast zulässig ist. Modell-Fallback und Anmeldeinformations-Fallback sind unterschiedliche Entscheidungen.
Ein Break-Glass-Schlüssel kann bei schwerwiegenden Ausfällen des Identitätsanbieters immer noch gerechtfertigt sein. Halten Sie es im Normalbetrieb deaktiviert oder unzugänglich. Die Aktivierung sollte eine authentifizierte Genehmigung erfordern, einen festen Ablauf haben, das Konto und die Vorgänge des betroffenen Anbieters einschränken und bei jeder damit verbundenen Anfrage eine Warnung auslösen. Seine Herkunft muss in der Anfragetelemetrie erscheinen.
Migrieren Sie jeweils einen Routing-Pool
- Inventory-Laufzeit- und Administratoranmeldeinformationen. Identifizieren Sie, welche Prozesse jeden einzelnen lesen können.
- Erstellen Sie eine dedizierte Arbeitslastidentität und ein eng begrenztes Anbieterdienstkonto.
- Konfigurieren Sie genaue Aussteller-, Zielgruppen-, Betreff- und Berechtigungszuordnungen.
- Fügen Sie eine Preflight-Prüfung hinzu, die ein Token abruft und einen zulässigen Endpunkt mit geringer Auswirkung aufruft.
- Canary einen kleinen Routing-Pool, der nur die Föderation verwendet. Lassen Sie den automatischen Schlüssel-Fallback während des Tests nicht aktiviert.
- Vergleichen Sie Authentifizierungsfehler, Austauschlatenz, Token-Alter und Anbieterautorisierungsergebnisse mit dem vorhandenen Pfad.
- Erhöhen Sie den Datenverkehr schrittweise und beobachten Sie mindestens einen vollständigen Token-Aktualisierungszyklus.
- Entfernen Sie den alten Schlüssel aus dem Laufzeitzugriff und widerrufen Sie ihn nach dem definierten Beobachtungszeitraum.
Wiederholen Sie diesen Vorgang je nach Anbieterkonto und Umgebung. Eine globale Umstellung macht es schwierig, einen Identitätszuordnungsfehler von einem anbieterspezifischen Token-Verhalten zu unterscheiden.
Instrumentieren und testen Sie die Fehlermodi
Token-Austauschlatenz, Aktualisierungsversuche, Aktualisierungsfehler, Alter der Anmeldeinformationen, Aussteller, zugeordnetes Hauptkonto, Anbieterkonto, Betriebsklasse und Authentifizierungsfehlerkategorie aufzeichnen. Zeichnen Sie niemals Zugriffstoken, externe Behauptungen, Clientgeheimnisse oder vollständige Autorisierungsheader auf.
Bevor die Föderation zum einzigen Produktionspfad wird, testen Sie:
- Uhrzeitunterschied zwischen Workern, Identitätsanbietern und Anbieter-Token-Diensten.
- Metadatenserver oder Workload-Identitätsendpunkt nicht verfügbar.
- Abgelaufene Behauptungen und falsche Zielgruppen.
- Rollenentfernung und Deaktivierung von Föderationsregeln.
- Token-Austauschdrosselung und temporärer Anbieter Fehler.
- Gleichzeitige Aktualisierung bei Spitzenverkehr.
- Signaturschlüsselrotation, während alte Token gültig bleiben.
Veröffentlichen Sie für die OIDC-Ausstellerrotation alte und neue Signaturschlüssel mit ausreichender Überlappung für Prüfer-Caches und ausgegebene Token. OpenAI dokumentiert ein 600-sekündiges Caching für Erkennungs- und Remote-JWKS-Daten mit einer JWKS-Aktualisierung, wenn ein Token auf eine unbekannte Schlüssel-ID verweist. Gehen Sie nicht davon aus, dass sich jeder Prüfer gleich verhält; Testrotation mit lebenden Kanarienvögeln.
Schlüssellose Laufzeitauthentifizierung als begrenzte Migration übernehmen
Das Ziel besteht nicht darin, zu behaupten, dass das Gateway keine Geheimnisse enthält. Es geht darum, langlebige Anbieterschlüssel von Laufzeitarbeitern mit hohem Volumen zu entfernen und unvermeidbare Administratoranmeldeinformationen auf eine kleinere Grenze der Steuerungsebene zu beschränken.
Beginnen Sie mit der Fähigkeitsmatrix, vermitteln Sie Anmeldeinformationen über eine Schnittstelle, puffern Sie sie nach Autorisierungskontext, verwenden Sie genaue Identitätszuordnungen und schließen Sie sie bei Austauschfehlern. Schließen Sie die Migration erst ab, nachdem Sie erfolgreiche Aktualisierungs-, Sperr-, Ausfall- und Signaturschlüsselrotationstests beobachtet haben. Dadurch entsteht ein schlüsselloser Laufzeitpfad, dessen Verfügbarkeit und Autorisierungsverhalten eher verstanden als angenommen wird.