OpenAI je svojim uradnim SDK-jem dodal vire združevanja identitete delovne obremenitve in objavil dokumentacijo za preverjanje pristnosti avtomatizacije API in Codex brez shranjevanja dolgotrajnih OpenAI poverilnic.

Sistem sprejema identitete, ki jih izdajo podprti oblak, CI in platforme delovne obremenitve, nato pa jih zamenja za kratkotrajne OpenAI dostopne žetone. OpenAI dokumentira podporo za vire identitete, vključno s storitvami Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud, Kubernetes, GitHub Actions in okolji, združljivimi s SPIFFE.

To je več kot SDK udobje. Organizacijam omogoča povezovanje obstoječega identifikacijskega sistema delovne obremenitve z OpenAI in omejitev škode, ki jo povzročijo uhajajoči, kopirani ali slabo zasukani ključi API. Prav tako spremeni, kaj morajo prehodi in platforme za razvijalce zabeležiti, ko preverjajo pristnost samodejnih delovnih obremenitev v imenu stranke.

Kako OpenAI deluje združevanje identitete delovnih obremenitev

Delovna obremenitev najprej pridobi poverilnico iz svojega izvornega okolja. Odvisno od platforme in storitve OpenAI je ta identiteta lahko predstavljena prek OpenID Connect, SPIFFE ali potrdila X.509. Nato se zamenja z začasnim žetonom dostopa OpenAI namesto z uporabo trajnega ključa API, vdelanega v konfiguracijo aplikacije.

OpenAI loči konfiguracijo na ponudnike identitete delovne obremenitve in zvezna pravila. Ponudnik določi, kateri zunanji identifikacijski sistem je zaupanja vreden. Zvezna pravila določajo, kako se identitete iz tega sistema preslikajo v OpenAI.

Za OpenAI API delovne obremenitve se lahko zunanja identiteta preslika v račun storitve projekta. V upravljanih Codex okoljih OpenAI dokumentira preslikave v uporabnike delovnega prostora ali storitvene račune. Ta razlika je pomembna, ker nenadzorovani zaledni proces običajno ne bi smel podedovati iste identitete in dovoljenj kot posamezni razvijalec.

Uradni izdaji Python in vozlišča SDK z datumom 3. november sta dodala ustvarjene vire za upravljanje ponudnikov identitete delovne obremenitve in zveznih pravil. OpenAI ni objavil ločenega članka o predstavitvi, ki bi opredeljeval natančen obseg uvajanja, zato bi morale organizacije pred načrtovanjem selitve potrditi primernost računa in razpoložljivost konfiguracije.

Zakaj so kratkotrajne poverilnice pomembne

Običajni ključi API so preprosti, vendar povzročajo operativne obveznosti. Ključ, kopiran v spremenljivko CI, sliko vsebnika ali skript za uvajanje, lahko ostane uporaben, dokler ga nekdo ne zavrti ali prekliče. Zveza nadomesti to stalno poverilnico z žetonom dostopa, ki izhaja iz identitete, ki jo delovna obremenitev že ima in ki poteče po omejenem obdobju.

Praktična korist je manjša izpostavljenost, ne odpornost proti ogrožanju. Zlonamerni proces, ki se izvaja v pooblaščenem okolju, lahko še vedno zahteva žeton in kliče API. Ekipe zato potrebujejo restriktivna zvezna pravila, storitvene račune OpenAI z ozkim obsegom, nadzor okoli zunanjega izdajatelja identitete in dnevnike, ki povezujejo vsako izmenjavo žetonov z delovno obremenitvijo, ki jo je sprožila.

GitHub Dejanja so primer takojšnje uporabe. Organizacija lahko uporabi identiteto delovnega toka, namesto da ključ OpenAI za večkratno uporabo namesti v repozitorij ali skrivnosti organizacije. Storitve, ki gostujejo v oblaku, in delovne obremenitve Kubernetes lahko sledijo istemu splošnemu vzorcu prek svojih izvornih sistemov identitete.

Posledice za prehode in partnerske platforme

Federacija uvaja novo pot preverjanja pristnosti za katero koli AI API nadzorno ravnino, ki jo uporabljajo skupine razvijalcev.Platforma ne more več domnevati, da je vsaka zahteva navzgor odobrena s statičnim ključem stranke. Morda bo moral ohraniti zunanjo identiteto delovne obremenitve, pridobiti ali sprejeti kratkotrajne žetone in povezati uporabo s pravilnim OpenAI računom storitve projekta.

Za prehod z več modeli funkcija izpostavlja tudi težavo s prenosljivostjo. Identity federation je specifičen za ponudnika, tudi če zahteve za sklepanje delijo obliko, združljivo z OpenAI. Podpora pri vseh prodajalcih zahteva ločeno konfiguracijo zaupanja, logiko izmenjave žetonov, obravnavanje poteka in poročanje o napakah. Poenotena končna točka ne ustvari samodejno poenotenega modela identitete.

Ista težava velja za AI API platformo preprodajalcev. Preslikava vsake delovne obremenitve stranke v storitveni račun ozkega obsega je varnejša od skupne rabe poverilnice na ravni organizacije, vendar mora platforma preprečiti, da bi se zunanja identiteta enega najemnika razrešila v OpenAI projekt drugega najemnika. Revizijski zapisi bi morali ohraniti zunanjo identiteto, zvezno pravilo, preslikanega OpenAI principala in posledično dodeljevanje uporabe.

Model Gate in podobne partnerske platforme bi lahko ovrednotile zvezo kot alternativo ključem ponudnika, ki jih zagotovijo stranke, za podprte poslovne integracije. To bi zahtevalo eksplicitno izolacijo najemnika in obravnavo življenjskega cikla, namesto da bi začasne žetone obravnavali kot običajne API ključe.

Kaj ostaja nejasno

Dokumentacija določa model preverjanja pristnosti in podprte kategorije ponudnika identitete, vendar več vprašanj o uvajanju ostaja specifičnih za račun. OpenAI v samostojni objavi ni jasno navedel, kateri načrti ali organizacije lahko takoj konfigurirajo zvezo. Dodatki SDK prikazujejo podporo odjemalcem, vendar tip SDK sam po sebi ne potrjuje, da ima vsak račun ustrezno pooblastilo za zaledje.

Obstaja tudi razlika v ravni storitve, ki jo je treba upoštevati: OpenAI dokumentira zvezo X.509 za pot API, ne pa tudi za pot Codex. Skupine bi morale preveriti vrsto poverilnice, ki jo podpira njihova predvidena storitev, namesto da domnevajo, da vsak mehanizem identitete velja enotno.

Organizacije, ki sprejmejo to funkcijo, morajo preizkusiti pridobitev žetona, potek, preklic in nadomestno vedenje, preden odstranijo obstoječe ključe. Glavna pridobitev je manjši odtis poverilnic z dolgo življenjsko dobo. Resnična varnost je še vedno odvisna od natančnih preslikav identitete, omejenih storitvenih računov in revizijske sledi, ki sledi delovni obremenitvi prek preverjanja pristnosti, sklepanja in zaračunavanja.