OpenAI dodał zasoby federacji tożsamości obciążenia do swoich oficjalnych zestawów SDK i opublikował dokumentację dotyczącą automatyzacji uwierzytelniania API i Codex bez przechowywania długotrwałych poświadczeń OpenAI.

System akceptuje tożsamości wydawane przez obsługiwane chmury, CI i platformy obciążeń, a następnie wymienia je na krótkotrwałe tokeny dostępu OpenAI. OpenAI obsługa dokumentów dla źródeł tożsamości, w tym Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud, Kubernetes, GitHub Actions i środowisk zgodnych z SPIFFE.

To więcej niż SDK wygoda. Daje organizacjom możliwość podłączenia istniejącego systemu identyfikacji obciążeń do OpenAI i ograniczenia szkód spowodowanych wyciekiem, skopiowaniem lub źle obróconymi kluczami API. Zmienia także to, jakie bramy i platformy programistów muszą rejestrować podczas uwierzytelniania zautomatyzowanych obciążeń w imieniu klienta.

Jak działa OpenAI federacja tożsamości obciążenia pracą

Obciążenie najpierw uzyskuje dane uwierzytelniające ze swojego natywnego środowiska. W zależności od platformy i usługi OpenAI tożsamość ta może być reprezentowana poprzez OpenID Connect Connect, SPIFFE lub certyfikat X.509. Następnie jest on wymieniany na tymczasowy token dostępu OpenAI, zamiast używać trwałego klucza API osadzonego w konfiguracji aplikacji.

OpenAI rozdziela konfigurację na dostawców tożsamości obciążenia i reguły federacyjne. Dostawca ustala, który zewnętrzny system tożsamości jest zaufany. Reguły federacji określają, w jaki sposób tożsamości z tego systemu są mapowane na OpenAI.

W przypadku obciążeń OpenAI API tożsamość zewnętrzna może zostać zmapowana na konto usługi projektu. W zarządzanych Codex środowiskach OpenAI dokumentuje mapowania na użytkowników obszaru roboczego lub konta usług. To rozróżnienie ma znaczenie, ponieważ nienadzorowany proces zaplecza zwykle nie powinien dziedziczyć tej samej tożsamości i uprawnień co indywidualny programista.

Oficjalne wydania Python i Node SDK z 3 listopada dodały wygenerowane zasoby do zarządzania dostawcami tożsamości obciążeń i regułami federacji. OpenAI nie opublikował jednak osobnego artykułu wprowadzającego, określającego dokładny zakres wdrożenia, dlatego organizacje powinny przed zaplanowaniem migracji potwierdzić uprawnienia konta i dostępność konfiguracji.

Dlaczego krótkotrwałe dane uwierzytelniające mają znaczenie

Konwencjonalne klucze API są proste, ale powodują zobowiązania operacyjne. Klucz skopiowany do zmiennej CI, obrazu kontenera lub skryptu wdrażania może pozostać przydatny, dopóki ktoś go nie zmieni lub nie unieważni. Federacja zastępuje to stałe poświadczenie tokenem dostępu pochodzącym z tożsamości, którą obciążenie już posiada i który wygasa po ograniczonym czasie.

Praktyczną korzyścią jest węższa ekspozycja, a nie odporność na kompromisy. Złośliwy proces działający w autoryzowanym środowisku może nadal zażądać tokenu i wywołać API. Dlatego zespoły potrzebują restrykcyjnych reguł federacji, kont usług OpenAI o wąskim zakresie, kontroli wokół zewnętrznego wystawcy tożsamości i dzienników łączących każdą wymianę tokenów z obciążeniem, które ją zainicjowało.

GitHub Akcje to jeden z natychmiastowych przypadków użycia. Organizacja może użyć tożsamości przepływu pracy zamiast umieszczać klucz OpenAI wielokrotnego użytku w sekretach repozytorium lub organizacji. Usługi hostowane w chmurze i obciążenia Kubernetes mogą działać zgodnie z tym samym ogólnym wzorcem w swoich natywnych systemach tożsamości.

Konsekwencje dla bram i platform partnerskich

Federacja wprowadza nową ścieżkę uwierzytelniania dla każdej AI API płaszczyzny kontrolnej używanej przez zespoły programistów.Platforma nie może już zakładać, że każde żądanie nadrzędne jest autoryzowane przez statyczny klucz klienta. Może być konieczne zachowanie tożsamości zewnętrznego obciążenia, uzyskanie lub zaakceptowanie krótkotrwałych tokenów i powiązanie użycia z właściwym kontem usługi projektu OpenAI.

W przypadku bramy obsługującej wiele modeli funkcja ta podkreśla również problem z przenośnością. Federacja tożsamości jest specyficzna dla dostawcy, nawet jeśli żądania wnioskowania mają format zgodny z OpenAI. Obsługa go u różnych dostawców wymaga osobnej konfiguracji zaufania, logiki wymiany tokenów, obsługi wygaśnięcia i raportowania błędów. Ujednolicony punkt końcowy nie tworzy automatycznie ujednoliconego modelu tożsamości.

Ten sam problem dotyczy platformy sprzedawcy AI API. Mapowanie każdego obciążenia klienta na konto usługi o wąskim zakresie jest bezpieczniejsze niż udostępnianie poświadczeń na poziomie organizacji, ale platforma musi zapobiegać rozpoznawaniu tożsamości zewnętrznej jednego dzierżawcy w projekcie OpenAI innego dzierżawcy. Rekordy audytu powinny zawierać tożsamość zewnętrzną, regułę federacji, zmapowany OpenAI podmiot główny i wynikające z niego przypisanie użycia.

Model Gate i podobne platformy partnerskie mogą ocenić federację jako alternatywę dla kluczy dostawcy dostarczonych przez klienta na potrzeby obsługiwanych integracji korporacyjnych. Wymagałoby to wyraźnej izolacji dzierżawcy i obsługi cyklu życia, a nie traktowania tokenów tymczasowych jak zwykłych kluczy API.

Co pozostaje niejasne

Dokumentacja określa model uwierzytelniania i obsługiwane kategorie dostawców tożsamości, ale kilka pytań dotyczących wdrożenia pozostaje specyficznych dla konta. OpenAI nie określił jasno w odrębnym ogłoszeniu, które plany lub organizacje mogą natychmiast skonfigurować federację. Dodatki SDK pokazują obsługę klienta, ale typ SDK sam w sobie nie potwierdza, że ​​każde konto ma odpowiednie uprawnienia do zaplecza.

Istnieje również różnica w poziomie usług: OpenAI dokumentuje federację X.509 dla ścieżki API, ale nie dla ścieżki Codex. Zespoły powinny zweryfikować typ danych uwierzytelniających obsługiwany przez ich zamierzoną usługę, zamiast zakładać, że każdy mechanizm tożsamości ma jednolite zastosowanie.

Organizacje stosujące tę funkcję powinny przetestować pozyskiwanie, wygaśnięcie, unieważnianie i zachowanie tokenu w przypadku tokenów przed usunięciem istniejących kluczy. Główną korzyścią jest mniejszy, długotrwały ślad poświadczeń. Prawdziwe bezpieczeństwo w dalszym ciągu zależy od precyzyjnych mapowań tożsamości, ograniczonych kont usług i ścieżki audytu śledzącej obciążenie pracą poprzez uwierzytelnianie, wnioskowanie i rozliczenia.