Sleutelloze upstream-authenticatie voor AI API-gateways: een federatiepatroon voor werkbelastingidentiteiten

Productiegatewaywerknemers mogen geen upstream API-sleutels met een lange levensduur bij zich hebben wanneer de provider de werklast zelf kan verifiëren. Het veiligere patroon is om een bestaande cloud-, Kubernetes-, CI- of SPIFFE-identiteit uit te wisselen voor een providerreferentie met een korte levensduur, deze inloggegevens correct in de cache op te slaan en deze te beperken tot de kleinste bruikbare autorisatiegrens.

Het moeilijke deel is niet de tokenuitwisseling. Het verwerkt ongelijkmatige providerondersteuning, gelijktijdige vernieuwingen, identiteitstoewijzing, uitzonderingen op het controlevlak, uitval en migratie zonder een verborgen terugval te creëren naar een breed bevoorrechte gedeelde sleutel.

Begin met authenticatiemogelijkheden, niet met een algemene sleutelloze instelling

Feit: Authenticatie-ondersteuning verschilt per provider en bewerking. OpenAI en Anthropic ondersteunen productietaakidentiteitsfederatie voor API productietaken. Azure OpenAI ondersteunt Microsoft Entra ID en beheerde identiteiten. Google Cloud ondersteunt gekoppelde serviceaccounts, standaardgegevens van applicaties en Workload Identity Federation voor externe productietaken. Runtime-inferentie en administratieve API's accepteren echter niet noodzakelijkerwijs dezelfde inloggegevens.

OpenAI werkbelastingidentiteitstokens kunnen momenteel bijvoorbeeld geen beheerderseindpunten API aanroepen. Een gateway kan de authenticatie daarom niet veilig weergeven als één veld op providerniveau, zoals auth_mode: federated.

Aanbeveling: Bouw een mogelijkhedenmatrix op basis van provideraccount, eindpuntfamilie, omgeving en bewerkingsklasse:

Sla deze matrix op als versiebeheerconfiguratie. Routetoelating moet een bewerking afwijzen wanneer de geconfigureerde identiteit niet kan voldoen aan de vereiste authenticatiemogelijkheden. Dit hoort thuis in een AI API-controlevlak voor ontwikkelaarsteams, niet in ongedocumenteerde omgevingsvariabelen voor individuele werknemers.

Zet een referentiemakelaar tussen routerings- en provideradapters

Provideradapters mogen geen metadatareferenties ophalen, beweringen construeren of tokenvernieuwing onafhankelijk beheren. Introduceer een credential broker met één smalle interface:

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
}

De inlogwaarde is gevoelig en moet in het geheugen of in een goedgekeurde kortstondige cache blijven. De autorisatiecontext registreert het providerproject, het serviceaccount, de bereiken, rollen of implementatiebeperkingen die door het token worden vertegenwoordigd. Herkomst geeft aan hoe het is verkregen, zoals oidc_exchange, managed_identity, adc of break_glass.

Dit contract houdt de routering provider-neutraal, terwijl de details behouden blijven die nodig zijn voor autorisatiecontroles en telemetrie. Het voorkomt ook dat een multi-model API gateway voor teams elk dragertoken als uitwisselbaar beschouwt.

Gebruik providerspecifieke acquisitieadapters

Elke acquisitieadapter mag alleen de stappen uitvoeren die door de provider worden vereist:

• Verkrijg een externe bewering van de lokale identiteitsbron, zoals een door Kubernetes geprojecteerd serviceaccounttoken, cloudmetagegevensservice of SPIFFE-werklast API.
• Vraag de exacte doelgroep op die wordt verwacht door de provider of de geconfigureerde federatieregel.
• Wissel de bewering uit wanneer de provider tokenuitwisseling vereist.
• Retourneer de resulterende bewering inloggegevens en gezaghebbende vervaltijd.
• Classificeer fouten als lokale identiteits-, uitwisselings-, autorisatie-, configuratie- of providerbeschikbaarheidsfouten.

Het OpenAI-compatibele eindpunt van Vertex AI is een nuttig voorbeeld van scheiding: een applicatie kan een Google toegangstoken verkrijgen via de standaardgegevens van de applicatie en dat token opgeven als de OpenAI klantreferentie. De protocoladapter blijft OpenAI-compatibel, terwijl het verkrijgen van inloggegevens Google-specifiek blijft.

Maak de tokencache autorisatiebewust

Feit: Federatieve inloggegevens zijn van korte duur. OpenAI toegangstokens voor werkbelastingidentiteiten duren niet langer dan één uur, kunnen de externe onderwerptoken of het geverifieerde certificaat niet overleven en worden uitgegeven zonder vernieuwingstokens. De werklast moet de uitwisseling herhalen vóór de vervaldatum.

Een cachesleutel moet elke dimensie bevatten die de resulterende autoriteit kan veranderen:

cache_key = hash(
  provider_account_id,
  workload_identity_id,
  target_service_account,
  audience,
  normalized_scopes,
  operation_class
)

Het weglaten van het doelaccount, de doelgroep of het bereik kan ertoe leiden dat een medewerker een geldig token hergebruikt in de verkeerde autorisatiecontext. Dat is gevaarlijker dan een cachemisser.

Vernieuw vóór de vervaldatum met een veiligheidsmarge en willekeurige jitter. Eén praktisch beleid is:

refresh_at = expires_at
             - max(configured_margin, token_lifetime * 0.10)
             - random_jitter

De exacte marge moet rekening houden met klokafwijking, uitwisselingslatentie, tijd voor nieuwe pogingen en het langst verwachte verzoek. Vernieuw niet uitsluitend op een vaste timer die losstaat van expires_at.

Voorkom beursstormen met vernieuwing in één vlucht

Wanneer veel verzoeken hetzelfde bijna verlopen token tegenkomen, zou slechts één uitvoering de uitwisseling moeten uitvoeren. Andere bellers moeten de bestaande inloggegevens blijven gebruiken zolang deze binnen het toegestane venster blijven, of kort wachten op het gedeelde vernieuwingsresultaat.

Gebruik een single-flight-vergrendeling per cachesleutel. Bij een implementatie met meerdere processen of meerdere knooppunten beslist u of elke werknemer zijn eigen cache mag onderhouden of dat de vernieuwingscoördinatie moet worden gedistribueerd. Een lokale cache is eenvoudiger maar verhoogt het uitwisselingsvolume. Een gedistribueerde cache vermindert het aantal uitwisselingen, maar breidt de grens van gevoelige tokens uit en vereist versleuteld transport, strikte toegangscontrole en zorgvuldige uitzetting.

Aanbeveling: geef de voorkeur aan in-proces caches, tenzij providerlimieten of vlootgrootte de noodzaak van een gedeelde tokenservice aantonen. Coördineer eerst de vernieuwingen binnen elk proces en meet vervolgens het uitwisselingsvolume.

Identiteiten binden aan exacte productieclaims

Federatie verplaatst vertrouwen van een opgeslagen sleutel naar identiteitsclaims. Een tolerante mapping kan daarom net zo gevaarlijk zijn als een gelekte gedeelde inloggegevens.

Valideer de uitgever en de beoogde doelgroep en koppel de mapping vervolgens aan onveranderlijke of streng gecontroleerde claims. Voor Kubernetes moet u de naamruimte en het serviceaccount opnemen in plaats van een werkbelasting in het cluster te vertrouwen. Voor CI beperkt u de opslagplaats, de werkstroom, de omgeving en de beschermde vertakking of implementatiecontext. Voor cloudidentiteiten wijst u een specifieke werklastprincipal toe in plaats van een hele tenant of organisatie.

Maak afzonderlijke upstream-serviceaccounts of beheerde identiteiten voor productie, fasering, achtergrondtaken en administratieve automatisering. Beperk elke identiteit tot de modellen, projecten, werkruimten, implementaties en API bewerkingen die deze nodig hebben.

Feit: OpenAI kan identiteitstoewijzingen voor werkbelastingen beperken met API-rechten. Anthropic koppelt uitgewisselde inloggegevens aan een serviceaccount en waarschuwt dat federatie slechts zo veilig is als de upstream-identiteitsconfiguratie. Beheerde identiteiten en cloud-IAM zijn op dezelfde manier afhankelijk van roltoewijzingen met een correct bereik.

Runtimegegevens scheiden van beheerdersgegevens

Een inferentiewerker mag nooit een organisatiebeheerdertoken erven alleen maar omdat een taak op het controlevlak er nog steeds een nodig heeft. Splits het systeem op in twee beveiligingsgrenzen:

• Runtimevlak: Verwerkt modelverzoeken en ontvangt alleen federatieve of beheerde inloggegevens met een bereik tot gevolgtrekking.
• Besturingsvlak: Voert project-, werkruimte-, facturerings- of serviceaccountbeheer uit via geïsoleerde taken met afzonderlijk opgeslagen inloggegevens en sterkere goedkeuringscontroles.

Beheerdersgegevens mogen geen pad hebben naar runtime-omgevingsvariabelen, podspecificaties, foutopsporingsbundels of tokencaches. Leg het gebruik ervan vast in hetzelfde auditsysteem dat alleen wordt toegevoegd en dat wordt gebruikt voor configuratiewijzigingen.

Fout gesloten zonder herstel geïmproviseerd

Aanbeveling: Vervang een mislukte federatie-uitwisseling niet automatisch door een gedeelde statische sleutel. Automatische terugval kan een ingetrokken toewijzing omzeilen, een onjuist publiek verbergen of de toegang herstellen die een identiteitsbeheerder opzettelijk heeft verwijderd.

Retourneer een geclassificeerde upstream-authenticatiefout, stop de verzending naar het betreffende provideraccount en sta toe dat het normale routeringsbeleid alleen een andere provider selecteert wanneer dat alternatief is toegestaan voor de tenant en de werklast. Model-fallback en referentie-fallback zijn verschillende beslissingen.

Een breekglassleutel kan nog steeds gerechtvaardigd zijn bij ernstige storingen bij de identiteitsprovider. Houd het uitgeschakeld of ontoegankelijk tijdens normaal gebruik. Voor activering moet een geverifieerde goedkeuring nodig zijn, een vaste vervaldatum hebben, de betrokken provideraccount en -bewerkingen worden beperkt en een waarschuwing worden gegeven bij elk verzoek dat daarmee wordt gedaan. De herkomst moet verschijnen in de telemetrie van verzoeken.

Eén routeringspool tegelijk migreren

1. Voorraadruntime en beheerdersreferenties. Identificeer welke processen ze allemaal kunnen lezen.
2. Maak een specifieke werklastidentiteit en een nauwgezet providerserviceaccount.
3. Configureer de exacte toewijzingen van uitgever, doelgroep, onderwerp en rechten.
4. Voeg een preflightcontrole toe die een token verkrijgt en een toegestaan ​​eindpunt met weinig impact aanroept.
5. Canary is een kleine routeringspool die alleen federatie gebruikt. Laat de automatische sleutelterugval niet ingeschakeld tijdens de test.
6. Vergelijk authenticatiefouten, uitwisselingslatentie, tokenleeftijd en providerautorisatieresultaten met het bestaande pad.
7. Vergroot het verkeer geleidelijk en observeer ten minste één volledige tokenvernieuwingscyclus.
8. Verwijder de oude sleutel uit runtime-toegang en trek deze vervolgens in na de gedefinieerde observatieperiode.

Herhaal dit proces per provideraccount en omgeving. Een globale cutover maakt het moeilijk om een identiteitstoewijzingsfout te onderscheiden van een providerspecifiek tokengedrag.

Instrueer en test de faalmodi

Registreer de latentie van de tokenuitwisseling, vernieuwingspogingen, vernieuwingsfouten, leeftijd van de inloggegevens, uitgever, toegewezen opdrachtgever, provideraccount, bewerkingsklasse en categorie van verificatiefouten. Registreer nooit toegangstokens, externe beweringen, clientgeheimen of volledige autorisatieheaders.

Voordat federatie het enige productiepad wordt, test:

• Klokafwijking tussen werkers, identiteitsproviders en providertokenservices.
• Onbeschikbaarheid van metadataserver of werkbelastingidentiteitseindpunt.
• Verlopen beweringen en onjuiste doelgroepen.
• Rolverwijdering en uitschakeling van federatieregels.
• Tokenuitwisselingsbeperking en tijdelijke provider fouten.
• Gelijktijdig vernieuwen tijdens piekverkeer.
• Roulatie van handtekeningsleutel terwijl oude tokens geldig blijven.

Voor rotatie van OIDC-uitgevers publiceert u oude en nieuwe ondertekeningssleutels met voldoende overlap voor verificatiecaches en uitgegeven tokens. OpenAI documenten Caching van 600 seconden voor ontdekking en externe JWKS-gegevens, met een JWKS-vernieuwing wanneer een token verwijst naar een onbekende sleutel-ID. Ga er niet vanuit dat elke verificateur zich identiek gedraagt; testrotatie met levende kanaries.

Gebruik sleutelloze runtime-authenticatie als een begrensde migratie

Het doel is niet om te beweren dat de gateway geen geheimen bevat. Het is bedoeld om providersleutels met een lange levensduur te verwijderen van runtimewerkers met een groot volume en om onvermijdelijke beheerdersreferenties te beperken tot een kleinere grens van het controlevlak.

Begin met de mogelijkhedenmatrix, makelaarsreferenties via één interface, cache op basis van autorisatiecontext, gebruik exacte identiteitstoewijzingen en mislukte afsluiting bij uitwisselingsfouten. Voltooi de migratie pas na succesvolle vernieuwings-, intrekkings-, uitval- en ondertekeningssleutelrotatietests. Dat levert een sleutelloos runtimepad op waarvan de beschikbaarheid en het autorisatiegedrag worden begrepen in plaats van aangenomen.

Gerelateerd lezen

• Het verifiëren van de inloggegevens van de provider voordat het productieverkeer wordt doorgestuurd