Autenticazione upstream senza chiave per gateway AI API: un modello di federazione delle identità del carico di lavoro

I lavoratori del gateway di produzione non devono trasportare chiavi API upstream di lunga durata quando il provider può autenticare il carico di lavoro stesso. Il modello più sicuro consiste nello scambiare un'identità cloud, Kubernetes, CI o SPIFFE esistente con credenziali di un provider di breve durata, memorizzare correttamente nella cache le credenziali e limitarle al limite di autorizzazione utile più piccolo.

La parte difficile non è lo scambio di token. Gestisce il supporto irregolare dei provider, gli aggiornamenti simultanei, la mappatura delle identità, le eccezioni del piano di controllo, le interruzioni e la migrazione senza creare un fallback nascosto a una chiave condivisa ampiamente privilegiata.

Inizia con funzionalità di autenticazione, non con un'impostazione globale senza chiave

Fatto: Il supporto dell'autenticazione varia in base al provider e all'operazione. OpenAI e Anthropic supportano la federazione delle identità dei carichi di lavoro per API carichi di lavoro. Azure OpenAI supporta l'ID Microsoft Entra e le identità gestite. Google Cloud supporta account di servizio collegati, credenziali predefinite dell'applicazione e federazione delle identità del carico di lavoro per carichi di lavoro esterni. Tuttavia, l'inferenza di runtime e le API amministrative non accettano necessariamente gli stessi tipi di credenziali.

Ad esempio, OpenAI token di identità del carico di lavoro attualmente non possono chiamare gli endpoint Admin API. Un gateway pertanto non può rappresentare in modo sicuro l'autenticazione come un campo a livello di provider come auth_mode: federated.

Raccomandazione: Crea una matrice di capacità identificata da account del provider, famiglia di endpoint, ambiente e classe operativa:

Memorizza questa matrice come configurazione con versione. L'ammissione del percorso dovrebbe rifiutare un'operazione quando la sua identità configurata non può soddisfare la capacità di autenticazione richiesta. Questo appartiene a un piano di controllo AI API per i team di sviluppatori, non a variabili di ambiente non documentate sui singoli lavoratori.

Inserisci un broker di credenziali tra il routing e gli adattatori del provider

Gli adattatori del provider non devono recuperare le credenziali dei metadati, costruire asserzioni o gestire l'aggiornamento dei token in modo indipendente. Presenta un broker di credenziali con un'unica interfaccia ristretta:

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
}

Il valore della credenziale è sensibile e deve rimanere in memoria o in una cache temporanea approvata. Il contesto di autorizzazione registra il progetto del provider, l'account di servizio, gli ambiti, i ruoli o le restrizioni di distribuzione rappresentate dal token. La provenienza identifica il modo in cui è stato acquisito, ad esempio oidc_exchange, managed_identity, adc o break_glass.

Questo contratto mantiene il routing indipendente dal fornitore preservando i dettagli necessari per i controlli di autorizzazione e la telemetria. Impedisce inoltre a un gateway multi-modello API per i team di considerare ogni token di connessione come intercambiabile.

Utilizza adattatori di acquisizione specifici del provider

Ogni adattatore di acquisizione deve eseguire solo i passaggi richiesti dal relativo fornitore:

• Ottieni un'asserzione esterna dall'origine dell'identità locale, ad esempio un token dell'account di servizio previsto Kubernetes, un servizio di metadati cloud o un carico di lavoro SPIFFE API.
• Richiedi il pubblico esatto previsto dal provider o dalla regola di federazione configurata.
• Scambia l'asserzione quando il provider richiede lo scambio di token.
• Restituisci il risultato data di scadenza delle credenziali e dell'autorità.
• Classifica gli errori come errori di identità locale, scambio, autorizzazione, configurazione o disponibilità del provider.

L'endpoint compatibile OpenAI di Vertex AI è un utile esempio di separazione: un'applicazione può ottenere un token di accesso Google tramite le credenziali predefinite dell'applicazione e fornire quel token come credenziale del client OpenAI. L'adattatore di protocollo rimane compatibile con OpenAI, mentre l'acquisizione delle credenziali rimane specifica con Google.

Rendi la cache dei token sensibile all'autorizzazione

Fatto: le credenziali federate hanno vita breve. OpenAI token di accesso all'identità del carico di lavoro durano non più di un'ora, non possono sopravvivere al token del soggetto esterno o al certificato verificato e vengono emessi senza token di aggiornamento. Il carico di lavoro deve ripetere lo scambio prima della scadenza.

Una chiave di cache deve includere ogni dimensione che può modificare l'autorità risultante:

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

L'omissione dell'account, del pubblico o degli ambiti di destinazione può far sì che un lavoratore riutilizzi un token valido nel contesto di autorizzazione sbagliato. Questo è più pericoloso di perdere la cache.

Aggiorna prima della scadenza utilizzando un margine di sicurezza e un jitter casuale. Una politica pratica è:

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

Il margine esatto deve tenere conto dello sfasamento dell'orologio, della latenza dello scambio, del tempo di ripetizione e della richiesta prevista più lunga. Non aggiornare esclusivamente in base a un timer fisso scollegato da expires_at.

Previeni tempeste di scambi con l'aggiornamento di un singolo volo

Quando molte richieste incontrano lo stesso token prossimo alla scadenza, solo un'esecuzione dovrebbe eseguire lo scambio. Gli altri chiamanti dovrebbero continuare a utilizzare le credenziali esistenti mentre rimangono all'interno della finestra consentita o attendere brevemente il risultato dell'aggiornamento condiviso.

Utilizza un blocco per singolo volo per chiave cache. In una distribuzione multiprocesso o multinodo, decidere se ciascun lavoratore può mantenere la propria cache o se il coordinamento dell'aggiornamento deve essere distribuito. Una cache locale è più semplice ma aumenta il volume di scambio. Una cache distribuita riduce gli scambi ma espande il limite dei token sensibili e richiede trasporto crittografato, controllo rigoroso degli accessi ed eliminazione attenta.

Raccomandazione: preferisci le cache in-process a meno che i limiti del provider o le dimensioni del parco risorse dimostrino la necessità di un servizio token condiviso. Prima coordina gli aggiornamenti all'interno di ciascun processo, quindi misura il volume degli scambi.

Lega le identità alle richieste esatte del carico di lavoro

La federazione sposta la fiducia da una chiave archiviata alle rivendicazioni di identità. Una mappatura permissiva può quindi essere pericolosa quanto una credenziale condivisa trapelata.

Convalida l'emittente e il pubblico previsto, quindi associa la mappatura ad affermazioni immutabili o strettamente controllate. Per Kubernetes, includi lo spazio dei nomi e l'account del servizio anziché fidarti di qualsiasi carico di lavoro nel cluster. Per CI, limitare il repository, il flusso di lavoro, l'ambiente e il ramo protetto o il contesto di distribuzione. Per le identità cloud, mappa un'entità del carico di lavoro specifica anziché un intero tenant o organizzazione.

Crea account di servizio upstream separati o identità gestite per produzione, gestione temporanea, processi in background e automazione amministrativa. Limita ciascuna identità ai modelli, progetti, aree di lavoro, distribuzioni e API operazioni necessarie.

Fatto: OpenAI può limitare le mappature delle identità del carico di lavoro con API autorizzazioni. Anthropic associa le credenziali scambiate con un account di servizio e avverte che la federazione è sicura quanto la configurazione dell'identità upstream. Allo stesso modo, le identità gestite e Cloud IAM dipendono dalle assegnazioni di ruolo con ambito corretto.

Separare le credenziali di runtime dalle credenziali amministrative

Un lavoratore di inferenza non dovrebbe mai ereditare un token di amministrazione dell'organizzazione semplicemente perché alcune attività del piano di controllo ne necessitano ancora. Suddividi il sistema in due limiti di sicurezza:

• Piano di runtime: Gestisce le richieste del modello e riceve solo credenziali federate o gestite con ambito inferenza.
• Piano di controllo: Esegue l'amministrazione di progetti, aree di lavoro, fatturazione o account di servizio tramite processi isolati con credenziali archiviate separatamente e controlli di approvazione più efficaci.

Le credenziali amministrative non devono avere alcun percorso nelle variabili di ambiente di runtime, nelle specifiche dei pod, nei bundle di debug o nelle cache dei token. Registra il loro utilizzo nello stesso sistema di controllo di sola aggiunta utilizzato per le modifiche alla configurazione.

Fail chiuso senza rendere improvvisato il ripristino

Raccomandazione: non sostituire automaticamente uno scambio federativo non riuscito con una chiave statica condivisa. Il fallback automatico può ignorare una mappatura revocata, nascondere un pubblico errato o ripristinare l'accesso rimosso intenzionalmente da un amministratore dell'identità.

Restituisce un errore di autenticazione upstream classificato, interrompe l'invio all'account del provider interessato e consente alla normale policy di routing di selezionare un altro provider solo quando tale alternativa è consentita per il tenant e il carico di lavoro. Il fallback del modello e quello delle credenziali sono decisioni diverse.

Una chiave "break-glass" può comunque essere giustificata in caso di gravi interruzioni del provider di identità. Mantenerlo disabilitato o inaccessibile durante il normale funzionamento. L'attivazione dovrebbe richiedere un'approvazione autenticata, avere una scadenza fissa, limitare l'account e le operazioni del fornitore interessato e avvisare per ogni richiesta effettuata con esso. La sua provenienza deve apparire nella telemetria della richiesta.

Migrazione di un pool di routing alla volta

1. Runtime dell'inventario e credenziali amministrative. Identifica quali processi possono leggere ciascuno di essi.
2. Crea un'identità del carico di lavoro dedicata e un account del servizio del provider con ambito ristretto.
3. Configura le mappature esatte di emittente, pubblico, oggetto e autorizzazioni.
4. Aggiungi un controllo preliminare che acquisisce un token e chiama un endpoint consentito a basso impatto.
5. Canaria un piccolo pool di routing utilizzando solo la federazione. Non lasciare abilitato il fallback automatico della chiave durante il test.
6. Confronta gli errori di autenticazione, la latenza di scambio, l'età del token e i risultati dell'autorizzazione del provider con il percorso esistente.
7. Aumenta il traffico gradualmente e osserva almeno un ciclo completo di aggiornamento del token.
8. Rimuovi la vecchia chiave dall'accesso runtime, quindi revocala dopo il periodo di osservazione definito.

Ripeti questa procedura per account e ambiente del fornitore. Un cutover globale rende difficile distinguere un errore di mappatura dell'identità da un comportamento del token specifico del provider.

Strumenti e test sulle modalità di guasto

Registra la latenza dello scambio di token, i tentativi di aggiornamento, gli errori di aggiornamento, l'età delle credenziali, l'emittente, l'entità mappata, l'account del fornitore, la classe dell'operazione e la categoria dell'errore di autenticazione. Non registrare mai token di accesso, asserzioni esterne, segreti client o intestazioni di autorizzazione complete.

Prima che la federazione diventi l'unico percorso di produzione, prova:

• Sfalsamento dell'orario tra nodi di lavoro, provider di identità e servizi token del provider.
• Indisponibilità del server di metadati o dell'endpoint identità del carico di lavoro.
• Assistenti scaduti e segmenti di pubblico errati.
• Rimozione del ruolo e disattivazione delle regole di federazione.
• Limitazione dello scambio di token e provider temporaneo errori.
• Aggiornamento simultaneo durante i picchi di traffico.
• Rotazione delle chiavi di firma mentre i vecchi token rimangono validi.

Per la rotazione degli emittenti OIDC, pubblica le chiavi di firma vecchie e nuove con una sovrapposizione sufficiente per le cache del verificatore e i token emessi. OpenAI documenta la memorizzazione nella cache di 600 secondi per il rilevamento e i dati JWKS remoti, con un aggiornamento JWKS quando un token fa riferimento a un ID chiave sconosciuto. Non dare per scontato che ogni verificatore si comporti in modo identico; prova la rotazione con canarini vivi.

Adotta l'autenticazione runtime senza chiave come migrazione limitata

L'obiettivo non è affermare che il gateway non contenga segreti. Si tratta di rimuovere le chiavi del provider di lunga durata dai lavoratori runtime ad alto volume e confinare le credenziali amministrative inevitabili a un confine più piccolo del piano di controllo.

Inizia con la matrice delle capacità, intermedia le credenziali tramite un'unica interfaccia, memorizza nella cache in base al contesto di autorizzazione, utilizza mappature di identità esatte e fallisci la chiusura in caso di errori di scambio. Completare la migrazione solo dopo aver osservato con successo i test di aggiornamento, revoca, interruzione e rotazione della chiave di firma. Ciò produce un percorso di runtime senza chiavi la cui disponibilità e comportamento di autorizzazione sono compresi anziché presupposti.

Lettura correlata

• verifica delle credenziali del provider prima di instradare il traffico di produzione