OpenAI pridal do svojich oficiálnych súprav SDK zdroje na federáciu identít pracovného zaťaženia a zverejnil dokumentáciu na autentifikáciu API a Codex automatizácie bez uloženia dlhodobých poverení OpenAI.
Systém akceptuje identity vydané podporovanými platformami cloudu, CI a pracovného zaťaženia a potom ich vymení za krátkodobé OpenAI prístupové tokeny. OpenAI podpora dokumentov pre zdroje identity vrátane Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud, Kubernetes, GitHub Actions a prostredia kompatibilné so SPIFFE.
Toto je viac než SDK pohodlie. Poskytuje organizáciám spôsob, ako pripojiť existujúci systém identity pracovného zaťaženia k OpenAI a obmedziť škody spôsobené únikmi, skopírovanými alebo zle otočenými kľúčmi API. Zmení sa aj to, čo musia brány a platformy pre vývojárov zaznamenávať, keď overujú automatizované pracovné zaťaženia v mene zákazníka.
Ako funguje OpenAI federácia identity pracovného zaťaženia
Pracovné zaťaženie najskôr získa poverenia zo svojho natívneho prostredia. V závislosti od platformy a služby OpenAI môže byť táto identita reprezentovaná prostredníctvom OpenID Connect, SPIFFE alebo certifikátu X.509. Potom sa vymení za dočasný prístupový token OpenAI namiesto použitia trvalého kľúča API vloženého do konfigurácie aplikácie.
OpenAI rozdeľuje konfiguráciu na poskytovateľov identity pracovného zaťaženia a pravidlá federácie. Poskytovateľ určí, ktorý externý identifikačný systém je dôveryhodný. Pravidlá federácie určujú, ako sa identity z tohto systému mapujú do OpenAI.
V prípade úloh OpenAI API možno externú identitu namapovať na účet projektovej služby. V spravovaných Codex prostrediach OpenAI dokumentuje mapovania na používateľov pracovného priestoru alebo servisné účty. Na tomto rozdiele záleží, pretože proces backendu bez obsluhy by za normálnych okolností nemal zdediť rovnakú identitu a povolenia ako individuálny vývojár.
Oficiálne vydania Python a Node SDK z 3. novembra pridali generované zdroje na správu poskytovateľov identity pracovného zaťaženia a pravidlá federácie. OpenAI však nezverejnila samostatný článok o spustení, ktorý by definoval presný rozsah zavádzania, takže organizácie by si mali pred plánovaním migrácie potvrdiť vhodnosť účtu a dostupnosť konfigurácie.
Prečo sú dôležité krátkodobé poverenia
Konvenčné API kľúče sú jednoduché, no vytvárajú prevádzkové záväzky. Kľúč skopírovaný do premennej CI, obrázka kontajnera alebo skriptu nasadenia môže zostať užitočný, kým ho niekto neotočí alebo neodvolá. Federácia nahradí toto trvalé poverenie prístupovým tokenom odvodeným od identity, ktorú už má pracovná náplň a ktorej platnosť vyprší po obmedzenom čase.
Praktickou výhodou je užšie vystavenie, nie imunita voči kompromisom. Škodlivý proces spustený v autorizovanom prostredí si môže vyžiadať token a zavolať číslo API. Tímy preto potrebujú reštriktívne pravidlá federácie, OpenAI servisné účty s úzkym rozsahom, ovládacie prvky týkajúce sa externého vydavateľa identity a denníky, ktoré spájajú každú výmenu tokenov s pracovným zaťažením, ktoré ju spustilo.
GitHub Actions je jedným z bezprostredných prípadov použitia. Organizácia môže použiť identitu pracovného postupu namiesto umiestňovania opakovane použiteľného kľúča OpenAI do tajomstva úložiska alebo organizácie. Služby hostené v cloude a úlohy Kubernetes sa môžu riadiť rovnakým všeobecným vzorom prostredníctvom ich natívnych systémov identity.
Dôsledky pre brány a partnerské platformy
Federácia predstavuje novú cestu overenia pre akúkoľvek AI API riadiacu rovinu používanú vývojárskymi tímami.Platforma už nemôže predpokladať, že každá upstream požiadavka je autorizovaná statickým zákazníckym kľúčom. Možno bude potrebné zachovať identitu externého pracovného zaťaženia, získať alebo prijať tokeny s krátkou životnosťou a priradiť použitie k správnemu účtu služby OpenAI projektu.
V prípade brány s viacerými modelmi táto funkcia tiež upozorňuje na problém s prenosnosťou. Federácia identity je špecifická pre poskytovateľa, aj keď požiadavky na odvodenie zdieľajú formát kompatibilný s OpenAI. Jeho podpora medzi dodávateľmi si vyžaduje samostatnú konfiguráciu dôveryhodnosti, logiku výmeny tokenov, spracovanie uplynutia platnosti a hlásenie porúch. Zjednotený koncový bod nevytvára automaticky model zjednotenej identity.
Rovnaký problém sa týka platformy predajcu AI API. Mapovanie každej pracovnej záťaže zákazníka na účet služby s úzkym rozsahom je bezpečnejšie ako zdieľanie poverení na úrovni organizácie, ale platforma musí zabrániť tomu, aby sa externá identita jedného nájomníka preniesla do projektu OpenAI iného nájomníka. Záznamy auditu by si mali zachovať externú identitu, pravidlo federácie, namapovaný princíp OpenAI a výsledné priradenie použitia.
Model Gate a podobné partnerské platformy môžu vyhodnotiť federáciu ako alternatívu k kľúčom poskytovateľa dodaných zákazníkom pre podporované podnikové integrácie. Vyžadovalo by si to explicitnú izoláciu nájomníkov a spracovanie životného cyklu, a nie zaobchádzanie s dočasnými tokenmi ako s obyčajnými kľúčmi API.
Čo zostáva nejasné
V dokumentácii sa stanovuje model overovania a podporované kategórie poskytovateľov identity, ale niekoľko otázok týkajúcich sa nasadenia zostáva špecifických pre účet. OpenAI v samostatnom oznámení jasne neuvádza, ktoré plány alebo organizácie môžu federáciu okamžite nakonfigurovať. Doplnky SDK zobrazujú podporu klienta, ale typ SDK sám o sebe nepotvrdzuje, že každý účet má zodpovedajúce oprávnenie na serveri.
Je tu tiež rozdiel na úrovni služby, ktorý treba sledovať: OpenAI dokumenty federácie X.509 pre cestu API, ale nie pre cestu Codex. Tímy by si mali overiť typ poverení podporovaný ich zamýšľanou službou namiesto toho, aby predpokladali, že každý mechanizmus identity platí jednotne.
Organizácie, ktoré si túto funkciu osvoja, by mali pred odstránením existujúcich kľúčov otestovať získavanie tokenov, ich vypršanie, zrušenie a záložné správanie. Hlavným ziskom je menšia dlhodobá poverovacia stopa. Skutočná bezpečnosť stále závisí od presného mapovania identity, obmedzených účtov služieb a audit trailu, ktorý sleduje pracovné zaťaženie prostredníctvom overovania, odvodzovania a fakturácie.