Przegląd
Strona Users zamienia hierarchięuser_path
stojącą za Twoimi kluczami API w drzewo grup i użytkowników i pozwala każdemu węzłowi
ograniczyć, z których modeli mogą korzystać requesty pod nim:
/acmei/acme/engto grupy – zawierają inne ścieżki./acme/eng/aliceto użytkownik – klucze API są przypisane bezpośrednio do niego.
Reguły
- Nowe klucze i węzły pozwalają na wszystko. Węzeł lub klucz bez
allowed_modelsnie nakłada żadnego własnego ograniczenia. - Wypisanie modeli ogranicza. Gdy węzeł wypisze modele, requesty pod nim mogą korzystać tylko z modeli pasujących do tej listy.
- Listy przecinają się w dół drzewa. Request musi spełniać listę dozwolonych modeli
swojego klucza API, swojej ścieżki użytkownika i każdego przodka aż do
/. Węzeł podrzędny może zawęzić to, na co pozwala jego grupa, ale nigdy tego nie poszerzy. - Reguły po stronie modeli nadal obowiązują. Polityka dostępu modelu wirtualnego, która ukrywa model przed poddrzewem, nadal go ukrywa.
GET /v1/models zwraca tylko modele, z których wywołujący może korzystać, więc klienci widzą
ten sam obraz, który egzekwuje gateway.
Requesty uwierzytelnione w inny sposób podlegają tym samym regułom ścieżek: sesja
OIDC SSO lub request zawierający tylko
nagłówek ścieżki użytkownika jest ograniczany przez polityki swojego user_path; tylko zarządzane
klucze API mają dodatkowo własną listę dozwolonych modeli. Master key nie ma przypisanej
ścieżki użytkownika: bez nagłówka nie ma ograniczeń, z nagłówkiem jest
ograniczany jak każdy inny request na tej ścieżce.
Jak ustalany jest dostęp
Polityki są zaczepione w drzewie ścieżek użytkownika i łączone od góry do dołu. Każda lista na drodze od korzenia do ścieżki requestu musi pasować, a lista samego klucza API jest stosowana na końcu: Dla pojedynczego requestu gateway sprawdza po kolei: Skąd pochodzą poszczególne elementy:
Węzeł bez listy nie wnosi niczego do łańcucha; ani nie poszerza, ani nie
zawęża. Dlatego nowy klucz lub nowa grupa zaczynają z dostępem do
wszystkiego i dlatego
/acme/sales powyżej nadal widzi obu providerów.
Selektory
Każdy wpis na liście dozwolonych modeli to jeden selektor:
Nazwy providerów muszą odpowiadać skonfigurowanemu providerowi; nieznane nazwy są odrzucane
przy zapisie polityki. Modele wirtualne nie są selektorami: alias lub load
balancer jest rozwiązywany do konkretnego modelu providera przed sprawdzeniem, więc zezwalaj
na modele docelowe, a nie na model wirtualny. Nazwa modelu wirtualnego na liście jest
akceptowana jako zwykły identyfikator modelu, ale nigdy niczego nie dopasowuje; load balancer, którego
cele obejmują różnych providerów, jest użyteczny tylko wtedy, gdy dozwolony jest każdy cel, który może wybrać,
w przeciwnym razie requesty kończą się błędem
400 za każdym razem, gdy wybierze niedozwolony cel.
Drzewo użytkowników pokazuje taki węzeł z pustą listą efektywną.
Przykład
Klucz API przypisany do
/acme/eng/alice z własnym
allowed_models: [anthropic/claude-sonnet-4-6] dodatkowo zawęża dostęp Alice do tego
jednego modelu.
Odrzucony request otrzymuje 400 z kodem model_access_denied.
Zarządzanie politykami
Dashboard
Users wyświetla każdy węzeł z jego własną listą dozwolonych modeli, jego modelami efektywnymi –
wynikiem na poziomie ścieżki po zastosowaniu jego własnej listy, list wszystkich rodziców i
polityk modeli wirtualnych po stronie modeli (czerwone None oznacza węzeł,
którego listy przecinają się do zbioru pustego) – oraz liczbą przypisanych do niego kluczy API.
Własne allowed_models zarządzanego klucza API może zawęzić request bardziej, niż
pokazuje ścieżka. Edytor ostrzega już w trakcie pisania, gdy
lista nie pozostawiłaby żadnego dostępnego modelu. Dodaj lub edytuj węzeł, żeby
ustawić jego modele; usuń politykę, żeby wrócić do limitów rodziców.
Liczba kluczy prowadzi do strony API Keys przefiltrowanej do poddrzewa tej ścieżki,
a każdy wiersz ma akcję Add API key, która otwiera formularz tworzenia klucza z
wstępnie wypełnioną ścieżką.
Listy dozwolonych modeli per klucz znajdują się na stronie API Keys: ustaw Allowed models przy
tworzeniu klucza lub edytuj je później z poziomu wiersza klucza. Jej kolumna Effective models
to ostateczna odpowiedź dla tych danych uwierzytelniających – połączenie polityk ścieżek, własnej
listy klucza i polityk po stronie modeli.
Konfiguracja
Zadeklaruj polityki wconfig.yaml pod users: (zobacz przykład powyżej) lub
w zmiennej środowiskowej USERS jako tablicę JSON z tymi samymi polami:
Admin API
POST /admin/auth-keys akceptuje allowed_models przy tworzeniu klucza. Kształty requestów i odpowiedzi
opisuje strona Endpointy administracyjne.