Jak usługa Workload Identity uwierzytelnia usługi w domowym stosie AI?
Tożsamość obciążenia uwierzytelnia domowe usługi AI, wiążąc krótkotrwałe poświadczenia kryptograficzne z poświadczonym procesem, a nie z adresem sieciowym lub zapisanym hasłem.
Lokalny interfejs API RAG, serwer modeli, wektorowa baza danych i brama narzędzi agenta mogą współdzielić jedną sieć domową, mając jednocześnie bardzo różne uprawnienia. Tożsamość obciążenia pozwala każdemu procesowi udowodnić, jaką zatwierdzoną usługą jest, zanim otrzyma dane lub poświadczenia. Weryfikator sprawdza dowody środowiska uruchomieniowego, wydaje nazwą tożsamość, a autoryzację zasobów pozostawia odrębnej decyzji dotyczącej polityki.
Poświadczenie łączy uruchomiony proces z zadeklarowaną tożsamością
Agent tożsamości obserwuje weryfikowalne właściwości środowiska uruchomieniowego, takie jak konto usługi, plik wykonywalny, obraz kontenera, przestrzeń nazw, host lub podpisane metadane obciążenia. Polityka rejestracji mapuje zaakceptowaną kombinację na stabilną nazwę usługi, zamiast ufać etykiecie zadeklarowanej przez samą usługę.
Praktyczna demonstracja poświadczania obciążenia w środowisku uruchomieniowym pokazuje, jak SPIFFE i SPIRE poświadczają obciążenia przed wydaniem tożsamości w homelabie. Początkowe zaufanie opiera się na węźle i procesie rejestracji, a nie na sekrecie skopiowanym do każdego kontenera.
Zmienia to pierwsze pytanie uwierzytelniania z „jaki adres IP się połączył?” na „które zatwierdzone obciążenie udowodniło posiadanie tej tożsamości?”. Dynamiczne adresy i ponowne uruchomienia kontenerów nie wymagają już nowego statycznego poświadczenia. Ta różnica pozostaje widoczna podczas późniejszych testów domowych.
Urząd tożsamości wydaje krótkotrwałe weryfikowalne poświadczenia
Po poświadczeniu urząd wydaje poświadczenie X.509 lub JWT zawierające identyfikator obciążenia i ograniczony czas ważności. Lokalny agent dostarcza je za pośrednictwem chronionego interfejsu obciążenia i odnawia przed wygaśnięciem. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja podejmie dalsze działania.
Omówienie krótkotrwałych poświadczeń obciążenia wyjaśnia, że tożsamości SPIFFE są krótkotrwałe i weryfikowalne kryptograficznie, co zmniejsza zależność od zakodowanych na stałe sekretów usług. Usługa odbierająca sprawdza wystawcę, odbiorcę, czas oraz dowód posiadania klucza. Tę granicę należy mierzyć oddzielnie w realistycznych warunkach działania.
Krótki czas ważności ogranicza ekspozycję po usunięciu lub przejęciu usługi. Odnawianie musi pozostać automatyczne, ponieważ wygasłe certyfikaty powinny kończyć działanie w sposób bezpieczny, zamiast skłaniać operatorów do przywracania kluczy długoterminowych. Praktyczne konsekwencje stają się widoczne, gdy kilka źródeł konkuruje o ograniczony kontekst.
Uwierzytelnianie dostarcza tożsamość, ale polityka przyznaje dostęp
Ważna tożsamość obciążenia potwierdza, która usługa wykonuje wywołanie; nie potwierdza jednak, że serwer modeli może odczytać każdą kolekcję ani że agent działa w imieniu konkretnego użytkownika. Autoryzacja ocenia tożsamość wraz z zasobem, operacją, delegowaniem przez użytkownika i aktualną polityką.
Analiza tożsamości obciążenia i agenta rozróżnia tożsamość obciążenia, wzajemne uwierzytelnianie oraz kontekst użytkownika lub agenta przenoszony powyżej połączenia. To rozdzielenie zapobiega przekształceniu zaufanego certyfikatu usługi w uniwersalne uprawnienie. Ta zależność powinna pozostać wyraźna w końcowym interfejsie.
Granica awarii obejmuje przejęty urząd tożsamości, poświadczający węzeł lub regułę rejestracji. Dowód kryptograficzny wiernie egzekwuje tożsamość, dla której został wydany, nawet jeśli polityka wydawania przypisała proces kontrolowany przez atakującego do niewłaściwej usługi.
Prześledź jedno wywołanie usługi od poświadczenia do autoryzacji
Wybierz żądanie RAG do magazynu wektorowego i zarejestruj selektor obciążenia, zarejestrowaną tożsamość, wystawcę, czas ważności certyfikatu lub tokenu, lokalizację klucza, walidację drugiej strony, żądany zasób, delegowanego użytkownika, decyzję polityki, odnowienie, unieważnienie i identyfikator audytu. Wynik musi zatem zostać sprawdzony względem pierwotnych dowodów.
Porównaj ten mechanizm z mechanizmami kontroli tożsamości AI. Przetestuj prawidłowe ponowne uruchomienie, skopiowane poświadczenie, niezarejestrowany kontener, niewłaściwego odbiorcę, wygasłą tożsamość, zmienione konto usługi oraz ważną tożsamość żądającą dostępu do niedozwolonej kolekcji. Ta różnica pozostaje widoczna podczas późniejszych testów domowych.
Uznaj test za zaliczony tylko wtedy, gdy autentyczne obciążenia łączą się ponownie automatycznie, a każda próba podszycia się lub przekroczenia uprawnień kończy się na nazwanej granicy. Chroń urząd tożsamości oddzielnie i utrzymuj autoryzację zasobów w węższym zakresie niż uwierzytelnianie usługi. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja podejmie dalsze działania.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Czym jest dryf osadzeń i kiedy prywatny indeks wyszukiwania wymaga przebudowy?
Odkoduj dryf modelu, przetwarzania wstępnego, korpusu i zapytań; odróżnij monitorowanie od niezgodności oraz zdecyduj, kiedy prywatny indeks wymaga przebudowy.
Czym jest zgodność tokenizera i dlaczego może zakłócić przełączanie modeli?
Odkryj tożsamość słownictwa, znaczenie tokenów specjalnych, szablony czatu, buforowane tokeny, adaptery i kontrole zgodności przy lokalnym przełączaniu modeli.
Czym jest rezydencja modelu i kiedy lokalna usługa AI powinna przechowywać wagi w pamięci?
Poznaj rezydencję wag, poziomy pamięci podręcznej, zimne uruchomienia, eksmisję, multipleksowanie, presję pamięci oraz dowiedz się, kiedy domowa usługa AI powinna pozostać aktywna.
