OpenAI добави ресурси за обединяване на идентификация на работното натоварване към своите официални SDK и публикува документация за удостоверяване на API и Codex автоматизация без съхраняване на дълготрайни OpenAI идентификационни данни.

Системата приема самоличности, издадени от поддържани облачни, CI и платформи за работно натоварване, след което ги обменя за краткотрайни OpenAI токени за достъп. OpenAI поддръжка на документи за източници на самоличност, включително Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud, Kubernetes, GitHub Actions и SPIFFE-съвместими среди.

Това е повече от SDK удобство. Той дава на организациите начин да свържат съществуваща система за идентификация на работното натоварване към OpenAI и да ограничат щетите, причинени от изтекли, копирани или лошо завъртани API ключове. Той също така променя това, което шлюзовете и платформите за разработчици трябва да записват, когато удостоверяват автоматизирани работни натоварвания от името на клиента.

Как OpenAI работи обединяването на самоличността на работните натоварвания

Работните натоварвания първо получават идентификационни данни от естествената си среда. В зависимост от платформата и услугата OpenAI тази идентичност може да бъде представена чрез OpenID Connect, SPIFFE или X.509 сертификат. След това се обменя за временен OpenAI маркер за достъп, вместо да се използва постоянен API ключ, вграден в конфигурацията на приложението.

OpenAI разделя конфигурацията на доставчици на идентичност за работно натоварване и правила за обединяване. Доставчикът установява коя външна система за идентификация е надеждна. Правилата за обединяване определят как самоличностите от тази система се преобразуват в OpenAI.

За OpenAI API работни натоварвания, външна самоличност може да бъде нанесена на акаунт за услуга на проект. В управлявани Codex среди, OpenAI документира съпоставяне към потребители на работно пространство или акаунти за услуги. Това разграничение има значение, тъй като необслужван бекенд процес обикновено не трябва да наследява същата самоличност и разрешения като индивидуален разработчик.

Официалните версии Python и Node SDK от 3 ноември добавиха генерирани ресурси за управление на доставчици на идентичност на работното натоварване и правила за обединяване. OpenAI обаче не е публикувал отделна статия за стартиране, определяща точния обхват на внедряване, така че организациите трябва да потвърдят допустимостта на акаунта и наличността на конфигурацията, преди да планират миграция.

Защо краткотрайните идентификационни данни имат значение

Конвенционалните API ключове са прости, но създават оперативни задължения. Ключ, копиран в CI променлива, изображение на контейнер или скрипт за внедряване, може да остане полезен, докато някой не го завърти или отмени. Федерацията заменя това постоянно удостоверение с токен за достъп, извлечен от самоличност, която работното натоварване вече притежава и което изтича след ограничен период.

Практическата полза е по-тясното излагане, а не имунитет срещу компрометиране. Злонамерен процес, който се изпълнява в оторизирана среда, все пак може да поиска токен и да извика API. Следователно екипите се нуждаят от ограничителни правила за обединяване, OpenAI акаунти за услуги с тесен обхват, контроли около външния издател на самоличност и регистрационни файлове, които свързват всеки обмен на токени с работното натоварване, което го е инициирало.

GitHub Действия е един случай на незабавна употреба. Една организация може да използва самоличността на работния поток, вместо да поставя ключ за многократна употреба OpenAI в хранилище или тайни на организация. Услугите, хоствани в облак, и работните натоварвания на Kubernetes могат да следват същия общ модел чрез собствените си системи за идентичност.

Последствия за шлюзове и партньорски платформи

Федерацията въвежда нов път за удостоверяване за всяка AI API контролна равнина, използвана от екипи за разработчици.Една платформа вече не може да приеме, че всяка заявка нагоре по веригата е разрешена от статичен клиентски ключ. Може да се наложи да запази самоличността на външното работно натоварване, да получи или приеме краткотрайни токени и да свърже използването с правилния OpenAI акаунт за услуга за проект.

За шлюз с няколко модела функцията също подчертава проблем с преносимостта. Федерирането на самоличност е специфично за доставчика дори когато заявките за извод споделят OpenAI-съвместим формат. Поддържането му от всички доставчици изисква отделна конфигурация на доверието, логика за обмен на токени, обработка на изтичане и докладване на грешки. Унифицираната крайна точка не създава автоматично унифициран модел на самоличност.

Същият проблем се отнася за AI API платформа за дистрибутори. Съпоставянето на всяко клиентско натоварване към акаунт за услуга с тесен обхват е по-безопасно от споделянето на идентификационни данни на ниво организация, но платформата трябва да попречи на външната самоличност на един клиент да се преобразува в OpenAI проект на друг клиент. Записите за одит трябва да запазят външната идентичност, правилото за обединяване, картографирания OpenAI принципал и произтичащото приписване на използването.

Model Gate и подобни партньорски платформи биха могли да оценят обединяването като алтернатива на предоставените от клиента ключове за доставчик за поддържани корпоративни интеграции. Това би изисквало изрично изолиране на клиента и обработка на жизнения цикъл, вместо третиране на временните токени като обикновени API ключове.

Какво остава неясно

Документацията установява модела за удостоверяване и поддържаните категории доставчици на самоличност, но няколко въпроса за внедряване остават специфични за акаунта. OpenAI не е посочил ясно в самостоятелно съобщение кои планове или организации могат да конфигурират незабавно обединяване. Добавките SDK показват клиентска поддръжка, но тип SDK сам по себе си не потвърждава, че всеки акаунт има съответните правомощия за бекенда.

Има и разлика в нивото на обслужване, която трябва да се наблюдава: OpenAI документира X.509 обединяване за пътя API, но не и за пътя Codex. Екипите трябва да проверят типа идентификационни данни, поддържан от предвидената им услуга, вместо да приемат, че всеки механизъм за самоличност се прилага еднакво.

Организациите, които приемат функцията, трябва да тестват поведението на придобиване на токени, изтичане, отмяна и резервно поведение, преди да премахнат съществуващите ключове. Основната печалба е по-малък дълготраен идентификационен отпечатък. Истинската сигурност все още зависи от прецизни съпоставяния на самоличността, ограничени акаунти за услуги и одитна пътека, която следва работното натоварване чрез удостоверяване, извод и таксуване.