Gateway
Zakresy operatora
Zakresy operatora ograniczają działania, które klient Gateway może wykonywać po uwierzytelnieniu. Stanowią mechanizm ochronny płaszczyzny sterowania w obrębie jednej zaufanej domeny operatora Gateway, a nie izolację przed wrogimi współdzierżawcami. Aby zapewnić silną separację między osobami, zespołami lub maszynami, uruchamiaj oddzielne instancje Gateway z użyciem oddzielnych użytkowników systemu operacyjnego lub hostów.
Powiązane: Bezpieczeństwo, Protokół Gateway, Parowanie Gateway, CLI urządzeń.
Role
Każdy klient WebSocket Gateway łączy się z jedną rolą:
operator: klienci płaszczyzny sterowania, takie jak CLI, interfejs sterowania, automatyzacja oraz zaufane procesy pomocnicze.node: hosty udostępniające funkcje (macOS, iOS, Android, bez interfejsu graficznego), które udostępniają polecenia za pośrednictwemnode.invoke.
Metody RPC operatora wymagają roli operator, natomiast metody pochodzące z węzła
wymagają roli node.
Poziomy zakresów
| Zakres | Znaczenie |
|---|---|
operator.read |
Stan tylko do odczytu, listy, katalog, dzienniki, odczyty sesji i inne wywołania niemodyfikujące. |
operator.write |
Działania operatora wprowadzające zmiany: wysyłanie wiadomości, wywoływanie narzędzi, aktualizowanie ustawień rozmowy/głosu, przekazywanie poleceń węzła. Spełnia również wymagania operator.read. |
operator.admin |
Dostęp administracyjny. Spełnia wymagania każdego zakresu operator.*. Wymagany do modyfikowania konfiguracji, aktualizacji, natywnych haków, zastrzeżonych przestrzeni nazw i zatwierdzania operacji wysokiego ryzyka. |
operator.pairing |
Zarządzanie parowaniem urządzeń i węzłów: wyświetlanie listy, zatwierdzanie, odrzucanie, usuwanie, rotacja i unieważnianie. |
operator.approvals |
Interfejsy API zatwierdzania wykonywania poleceń i pluginów. |
operator.talk.secrets |
Odczytywanie konfiguracji rozmowy wraz z sekretami. |
Nieznane przyszłe zakresy operator.* wymagają dokładnego dopasowania, chyba że wywołujący
ma już zakres operator.admin.
Zakres metody jest tylko pierwszą bramą
Każde wywołanie RPC Gateway ma zakres metody zgodny z zasadą najmniejszych uprawnień, który określa, czy żądanie dotrze do jego procedury obsługi. Niektóre procedury obsługi stosują następnie bardziej rygorystyczne kontrole zależne od konkretnego zatwierdzanego lub modyfikowanego elementu:
device.pair.approvejest dostępne z zakresemoperator.pairing, ale zatwierdzenie urządzenia operatora może utworzyć lub zachować wyłącznie zakresy, które wywołujący już ma.node.pair.approvejest dostępne z zakresemoperator.pairing, a następnie wyznacza dodatkowe zakresy zatwierdzania na podstawie zadeklarowanej listy poleceń oczekującego węzła.chat.sendjest metodą wymagającą zakresu zapisu, ale polecenia czatu/config seti/config unsetwymagają dodatkowooperator.admin, niezależnie od zakresu wysyłania wiadomości na czacie posiadanego przez wywołującego.
Pozwala to operatorom o niższych zakresach wykonywać działania związane z parowaniem o niskim ryzyku bez wymagania uprawnień administratora dla wszystkich zatwierdzeń parowania.
Zatwierdzanie parowania urządzeń
Rekordy parowania urządzeń są trwałym źródłem zatwierdzonych ról i zakresów. Już sparowane urządzenie nie uzyskuje po cichu szerszego dostępu: ponowne połączenie żądające szerszej roli lub szerszych zakresów tworzy nowe oczekujące żądanie rozszerzenia uprawnień.
Zatwierdzanie żądania urządzenia:
- Żądanie bez roli operatora nie wymaga zatwierdzenia zakresu operatora.
- Żądanie roli urządzenia innej niż operator (na przykład
node) wymagaoperator.admin, mimo że samodevice.pair.approvewymaga jedynieoperator.pairing. - Żądanie zakresu
operator.read,operator.write,operator.approvals,operator.pairingluboperator.talk.secretswymaga, aby wywołujący już miał ten zakres albooperator.admin. - Żądanie zakresu
operator.adminwymagaoperator.admin. - Żądanie naprawy bez jawnie określonych zakresów może odziedziczyć zakresy istniejącego tokenu
operatora; jeśli ten token ma zakres administracyjny, zatwierdzenie nadal wymaga
operator.admin.
Sesje bez uprawnień administratora korzystające ze współdzielonego sekretu lub zaufanego serwera proxy mogą zatwierdzać wyłącznie
żądania urządzeń operatora mieszczące się w ich własnych zadeklarowanych zakresach operatora; zatwierdzanie
ról innych niż operator wymaga uprawnień administratora, nawet jeśli te sesje mogą poza tym używać
operator.pairing.
W przypadku sesji tokenów sparowanych urządzeń zarządzanie jest ograniczone do własnego urządzenia, chyba że wywołujący
ma operator.admin: wywołujący bez uprawnień administratora widzi wyłącznie własne wpisy parowania i
może zatwierdzać, odrzucać, rotować, unieważniać lub usuwać wyłącznie wpis własnego urządzenia.
Zatwierdzanie parowania węzłów
Starsze metody node.pair.* korzystają z oddzielnego magazynu parowania węzłów zarządzanego przez Gateway.
Węzły WS korzystają zamiast tego z parowania urządzeń (role: node), ale obowiązuje ten sam zestaw
pojęć związanych z zatwierdzaniem. Informacje o relacji między tymi dwoma
magazynami zawiera sekcja Parowanie Gateway.
node.pair.approve wyznacza dodatkowe wymagane zakresy na podstawie listy poleceń
oczekującego żądania:
| Zadeklarowane polecenia | Wymagane zakresy |
|---|---|
| brak | operator.pairing |
| polecenia węzła niewykonujące procesów | operator.pairing + operator.write |
system.run, system.run.prepare lub system.which |
operator.pairing + operator.admin |
Zatwierdzenie deklaracji węzła nie włącza poleceń, które mają oddzielną
bramę listy dozwolonych operacji czasu wykonywania. Na przykład zatwierdzenie węzła deklarującego
computer.act wymaga zakresu parowania i zapisu, ale jedynie rejestruje ten interfejs.
Administrator lub właściciel nadal musi aktywować computer.act. Dopóki pozostaje ono
aktywne, wywoływanie go za pośrednictwem wymagającej zakresu zapisu metody node.invoke nie
wymaga zakresu administracyjnego dla każdego działania.
Parowanie węzła ustanawia tożsamość i zaufanie; nie zastępuje własnych zasad zatwierdzania
wykonywania poleceń system.run przez węzeł.
Uwierzytelnianie współdzielonym sekretem
Uwierzytelnianie za pomocą współdzielonego tokenu/hasła Gateway jest traktowane jako zaufany dostęp operatora do
tego Gateway. Interfejsy HTTP zgodne z OpenAI, /tools/invoke oraz punkty końcowe HTTP
historii sesji przywracają pełny domyślny zestaw zakresów operatora w przypadku uwierzytelniania typu bearer
za pomocą współdzielonego sekretu, nawet jeśli wywołujący przesyła węższe zadeklarowane zakresy.
Tryby przekazujące tożsamość, takie jak uwierzytelnianie przez zaufany serwer proxy lub none dla prywatnego ruchu przychodzącego,
mogą nadal respektować jawnie zadeklarowane zakresy. Aby zapewnić rzeczywistą separację granic zaufania,
używaj oddzielnych instancji Gateway.