Preverjanje pristnosti navzgor brez ključa za prehode AI API: zvezni vzorec identitete delovne obremenitve

Delavci produkcijskega prehoda ne smejo imeti dolgotrajnih ključev navzgor API, ko lahko ponudnik sam overi delovno obremenitev. Varnejši vzorec je zamenjava obstoječe identitete v oblaku, Kubernetes, CI ali SPIFFE za kratkotrajno poverilnico ponudnika, pravilno predpomnitev te poverilnice in omejitev na najmanjšo uporabno avtorizacijsko mejo.

Težaven del ni izmenjava žetonov. Obravnava neenakomerno podporo ponudnika, sočasne osvežitve, preslikavo identitete, izjeme nadzorne ravnine, izpade in selitev, ne da bi ustvaril skrito nadomestno možnost na ključ v skupni rabi s širokimi privilegiji.

Začnite z zmožnostmi preverjanja pristnosti, ne z globalno nastavitvijo brez ključa

Dejstvo: Podpora za preverjanje pristnosti se razlikuje glede na ponudnika in delovanje. OpenAI in Anthropic podpirata zvezo identitete delovne obremenitve za API delovne obremenitve. Azure OpenAI podpira Microsoft Entra ID in upravljane identitete. Google Oblak podpira priložene storitvene račune, privzete poverilnice aplikacije in Workload Identity Federation za zunanje delovne obremenitve. Vendar pa API-ji med izvajanjem in skrbništvom ne sprejemajo nujno istih vrst poverilnic.

Na primer, OpenAI žetoni identitete delovne obremenitve trenutno ne morejo klicati skrbniških API končnih točk. Prehod torej ne more varno predstavljati avtentikacije kot eno polje na ravni ponudnika, kot je auth_mode: federated.

Priporočilo: Zgradite matriko zmogljivosti, ki jo določa račun ponudnika, družina končnih točk, okolje in razred delovanja:

Shrani to matriko kot konfiguracijo z različicami. Dopust poti bi moral zavrniti operacijo, če njena konfigurirana identiteta ne more zadostiti zahtevani zmožnosti preverjanja pristnosti. To spada v AI API nadzorno raven za skupine razvijalcev, ne v nedokumentirane spremenljivke okolja na posameznih delavcih.

Postavite posrednika poverilnic med vmesnike usmerjanja in ponudnika

Vmesniki ponudnika ne smejo neodvisno pridobivati poverilnic metapodatkov, sestavljati trditev ali upravljati osveževanja žetonov. Predstavite posrednika poverilnic z enim ozkim vmesnikom:

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
}

Vrednost poverilnice je občutljiva in mora ostati v pomnilniku ali odobrenem efemernem predpomnilniku. Kontekst avtorizacije beleži ponudnikov projekt, storitveni račun, obsege, vloge ali omejitve razmestitve, ki jih predstavlja žeton. Izvor določa, kako je bilo pridobljeno, na primer oidc_exchange, managed_identity, adc ali break_glass.

Ta pogodba ohranja nevtralnost ponudnika usmerjanja, hkrati pa ohranja podrobnosti, potrebne za preverjanje avtorizacije in telemetrijo. Prav tako preprečuje večmodelnemu API prehodu za ekipe, da bi vsak žeton nosilca obravnaval kot zamenljivega.

Uporabite adapterje za pridobitev, specifične za ponudnika

Vsak adapter za pridobitev mora izvajati samo korake, ki jih zahteva njegov ponudnik:

• Pridobite zunanjo trditev iz lokalnega vira identitete, kot je žeton predvidenega storitvenega računa Kubernetes, metapodatkovna storitev v oblaku ali delovna obremenitev SPIFFE API.
• Zahtevajte točno tisto občinstvo, ki ga pričakuje ponudnik ali konfigurirano zvezno pravilo.
• Izmenjajte trditev, ko ponudnik zahteva žeton izmenjava.
• Vrni dobljeno poverilnico in avtoritativni čas veljavnosti.
• Razvrsti napake kot napake lokalne identitete, izmenjave, avtorizacije, konfiguracije ali razpoložljivosti ponudnika.

OpenAI-združljiva končna točka Vertex AI je uporaben primer ločevanja: aplikacija lahko pridobi Google dostopni žeton prek privzetih poverilnic aplikacije in ta žeton posreduje kot OpenAI poverilnico odjemalca. Adapter protokola ostaja OpenAI-združljiv, medtem ko pridobitev poverilnic ostaja Googlespecifična.

Omogočanje avtorizacije predpomnilnika žetonov

Dejstvo: Zvezne poverilnice so kratkotrajne. OpenAI Žetoni za dostop do identitete delovne obremenitve ne trajajo več kot eno uro, ne morejo preživeti zunanjega predmetnega žetona ali preverjenega potrdila in so izdani brez žetonov osveževanja. Delovna obremenitev mora ponoviti izmenjavo pred potekom.

Ključ predpomnilnika mora vključevati vsako dimenzijo, ki lahko spremeni nastalo avtoriteto:

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

Če izpustite ciljni račun, občinstvo ali obsege, lahko delavec znova uporabi veljaven žeton v napačnem avtorizacijskem kontekstu. To je bolj nevarno kot zgrešeni predpomnilnik.

Osveži pred iztekom z uporabo varnostne rezerve in naključnega tresenja. En praktični pravilnik je:

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

Natančna marža mora upoštevati poševnost ure, zakasnitev izmenjave, čas ponovnega poskusa in najdaljšo pričakovano zahtevo. Ne osvežujte samo s fiksnim časovnikom, ločenim od expires_at.

Preprečite izmenjavo neviht z osvežitvijo v enem letu

Ko veliko zahtev naleti na isti žeton skoraj poteče, mora zamenjavo izvesti samo ena izvedba. Drugi kličoči naj nadaljujejo z uporabo obstoječe poverilnice, medtem ko ostane v dovoljenem oknu, ali na kratko počakajo na rezultat osveževanja v skupni rabi.

Uporabite enosmerno zaklepanje na predpomnilnik. Pri razmestitvi z več procesi ali z več vozlišči se odločite, ali lahko vsak delavec vzdržuje svoj predpomnilnik ali pa mora biti koordinacija osveževanja porazdeljena. Lokalni predpomnilnik je preprostejši, vendar poveča količino izmenjave. Porazdeljeni predpomnilnik zmanjša izmenjave, vendar razširi mejo občutljivih žetonov in zahteva šifriran prenos, strog nadzor dostopa in skrbno izgon.

Priporočilo: Dajte prednost predpomnilnikom v procesu, razen če omejitve ponudnika ali velikost voznega parka kažejo na potrebo po storitvi skupnega žetona. Najprej koordinirajte osvežitve znotraj vsakega procesa, nato izmerite obseg izmenjave.

Povezovanje identitet z natančnimi zahtevki za delovno obremenitev

Federacija premakne zaupanje s shranjenega ključa na zahteve glede identitete. Permisivna preslikava je torej lahko enako nevarna kot razkrita skupna poverilnica.

Preverite izdajatelja in predvideno občinstvo, nato pa preslikavo povežite z nespremenljivimi ali strogo nadzorovanimi trditvami. Za Kubernetes vključite imenski prostor in račun storitve, namesto da zaupate kateri koli delovni obremenitvi v gruči. Za CI omejite repozitorij, potek dela, okolje in zaščiteno vejo ali kontekst razmestitve. Za identitete v oblaku preslikajte določenega principala delovne obremenitve namesto celotnega najemnika ali organizacije.

Ustvarite ločene storitvene račune navzgor ali upravljane identitete za proizvodnjo, uprizarjanje, opravila v ozadju in administrativno avtomatizacijo. Omejite vsako identiteto na modele, projekte, delovne prostore, uvedbe in API operacije, ki jih potrebuje.

Dejstvo: OpenAI lahko omeji preslikave identitete delovne obremenitve z dovoljenji API. Anthropic sodelavci so izmenjali poverilnice s servisnim računom in opozarjajo, da je zveza varna le toliko, kot je varna konfiguracija identitete navzgor. Upravljane identitete in IAM v oblaku so podobno odvisni od pravilno določenih dodelitev vlog.

Ločite poverilnice za čas izvajanja od skrbniških poverilnic

Sklepni delavec ne bi smel nikoli podedovati skrbniškega žetona organizacije samo zato, ker ga neka naloga nadzorne ravnine še vedno potrebuje. Razdelite sistem na dve varnostni meji:

• Izvajalna ravnina: Obravnava zahteve modela in prejema samo zvezne ali upravljane poverilnice, ki obsegajo sklepanje.
• Nadzorna ravnina: Izvaja upravljanje projektov, delovnega prostora, obračunavanja ali storitvenega računa prek izoliranih opravil z ločeno shranjenimi poverilnicami in strožjo odobritvijo kontrole.

Skrbniške poverilnice ne smejo imeti poti do spremenljivk izvajalnega okolja, specifikacij podov, svežnjev za odpravljanje napak ali predpomnilnikov žetonov. Zabeležite njihovo uporabo v istem revizijskem sistemu samo za dodajanje, ki se uporablja za spremembe konfiguracije.

Napaka zaprta brez improvizirane obnovitve

Priporočilo: Neuspešne zvezne izmenjave ne zamenjajte samodejno s statičnim ključem v skupni rabi. Samodejna nadomestna rešitev lahko obide preklicano preslikavo, prikrije nepravilno ciljno skupino ali obnovi dostop, ki ga je skrbnik identitete namerno odstranil.

Vrni klasificirano napako pri preverjanju pristnosti navzgor, ustavi odpošiljanje do prizadetega računa ponudnika in dovoli običajnemu pravilniku usmerjanja, da izbere drugega ponudnika samo, če je ta možnost dovoljena za najemnika in delovno obremenitev. Nadomestni model in nadomestna poverilnica sta različni odločitvi.

Ključ za razbijanje stekla je lahko še vedno upravičen pri resnih izpadih ponudnika identitete. Med normalnim delovanjem naj bo onemogočen ali nedostopen. Aktivacija bi morala zahtevati overjeno odobritev, imeti določen potek, omejiti prizadeti račun ponudnika in operacije ter opozoriti na vsako zahtevo, vloženo z njim. Njegov izvor mora biti prikazan v telemetriji zahtev.

Preseljevanje enega usmerjevalnega področja naenkrat

1. Čas izvajanja inventarja in skrbniške poverilnice. Ugotovite, kateri procesi lahko berejo vsakega od njih.
2. Ustvarite namensko identiteto delovne obremenitve in račun storitve ponudnika z ozkim obsegom.
3. Konfigurirajte natančne preslikave izdajatelja, ciljne skupine, subjekta in dovoljenj.
4. Dodajte preverjanje pred tiskom, ki pridobi žeton in pokliče dovoljeno končno točko z majhnim vplivom.
5. Canary a majhno usmerjevalno skupino, ki uporablja samo zvezo. Med preizkusom ne pustite omogočene samodejne zamenjave ključa.
6. Primerjajte napake pri preverjanju pristnosti, zakasnitev izmenjave, starost žetona in rezultate avtorizacije ponudnika z obstoječo potjo.
7. Postopoma povečujte promet in upoštevajte vsaj en celoten cikel osveževanja žetona.
8. Odstranite stari ključ iz dostopa med izvajanjem in ga nato prekličite po definiranem opazovanju obdobje.

Ponovite ta postopek za račun ponudnika in okolje. Zaradi globalnega preklopa je težko razlikovati napako preslikave identitete od vedenja žetona, specifičnega za ponudnika.

Instrumentirajte in preizkusite načine napak

Zakasnitev izmenjave žetonov, poskusi osveževanja, neuspešne osvežitve, starost poverilnice, izdajatelj, preslikani principal, račun ponudnika, operacijski razred in kategorija napak pri preverjanju pristnosti. Nikoli ne beležite žetonov dostopa, zunanjih trditev, skrivnosti odjemalca ali celotnih avtorizacijskih glav.

Preden združevanje postane edina proizvodna pot, preizkusite:

• Neskladje med delavci, ponudniki identitete in storitvami žetonov ponudnika.
• Nerazpoložljivost končne točke identitete metapodatkovnega strežnika ali delovne obremenitve.
• Pretekle trditve in nepravilne ciljne skupine.
• Odstranitev vloge in pravilo združevanja onemogočanje.
• Dušenje izmenjave žetonov in začasne napake ponudnika.
• Sočasno osveževanje pod največjim prometom.
• Rotacija podpisnega ključa, medtem ko stari žetoni ostanejo veljavni.

Za rotacijo izdajateljev OIDC objavite stare in nove podpisne ključe z zadostnim prekrivanjem za predpomnilnike preveriteljev in izdane žetone. OpenAI dokumentira 600-sekundno predpomnjenje za odkrivanje in oddaljene podatke JWKS z osvežitvijo JWKS, ko se žeton sklicuje na neznan ID ključa. Ne domnevajte, da se vsak preveritelj obnaša enako; preizkusite rotacijo z živimi kanarčki.

Sprejmite avtentikacijo med izvajanjem brez ključa kot omejeno selitev

Cilj ni trditi, da prehod ne vsebuje skrivnosti. Gre za odstranitev dolgotrajnih ključev ponudnika iz izvajalnih delavcev velikega obsega in omejitev neizogibnih skrbniških poverilnic na manjšo mejo nadzorne ravnine.

Začnite z matriko zmogljivosti, posredniškimi poverilnicami prek enega vmesnika, predpomnite po avtorizacijskem kontekstu, uporabite natančne preslikave identitete in neuspešno zaprtje zaradi napak pri izmenjavi. Selitev dokončajte šele po opazovanju uspešnih preizkusov osveževanja, preklica, izpada in rotacije podpisovanja ključev. To ustvari pot izvajanja brez ključa, katere razpoložljivost in avtorizacijsko vedenje sta razumljena in ne domnevna.

Sorodno branje

• preverjanje poverilnic ponudnika pred usmerjanjem produkcijskega prometa