Przejdź do treści
PentAGI
Konfiguracja

Bezpieczeństwo

Poświadczenia, HTTPS, logowanie i ekspozycja sieciowa instalacji PentAGI.

Zmień ustawienia domyślne

Świeża instalacja tworzy lokalnego administratora [email protected] z hasłem admin, które należy zmienić przy pierwszym logowaniu. Jeśli hasło zostanie utracone, menu serwisowe instalatora zresetuje je, pod warunkiem że konto nadal używa adresu [email protected].

Ustaw te wartości w .env przed pierwszym uruchomieniem; instalator generuje za Ciebie sól i hasła. PostgreSQL i Neo4j pobierają swoje dane uwierzytelniające tylko podczas tworzenia woluminów danych, więc późniejsza ich zmiana zrywa połączenie:

ZmiennaPrzeznaczenie
COOKIE_SIGNING_SALTPodpisuje ciasteczka sesji i tokeny API — ustaw losową wartość
PENTAGI_POSTGRES_USER, PENTAGI_POSTGRES_PASSWORDPoświadczenia PostgreSQL
NEO4J_PASSWORDHasło Neo4j do knowledge graph; NEO4J_USER musi pozostać neo4j
PUBLIC_URLAdres URL otwierany przez użytkowników, na przykład https://pentagi.example.com

Na działającej instalacji najpierw zmień hasło do bazy danych w PostgreSQL lub Neo4j, a następnie w .env.

HTTPS

PentAGI udostępnia HTTPS na porcie 8443 z certyfikatem samopodpisanym. Aby użyć własnego, ustaw SERVER_SSL_CRT i SERVER_SSL_KEY oraz zamontuj pliki w docker-compose.yml.

Użytkownicy i logowanie

Nie ma formularza rejestracji. Administratorzy zarządzają użytkownikami lokalnymi przez Users API (/api/v1/users/) z poziomu sesji przeglądarki po zalogowaniu — token API zwraca tam 403 — a role ograniczają to, co każdy użytkownik może zobaczyć i zmienić. Użytkownicy lokalni zmieniają swój własny adres e-mail i hasło w sekcji Settings → Account.

Przy skonfigurowanym logowaniu przez GitHub lub Google, logowanie, którego zweryfikowany przez dostawcę adres e-mail pasuje do istniejącego konta (w tym kont lokalnych), powoduje zalogowanie się na to konto z jego rolą; każde inne logowanie tworzy nowe konto z domyślną rolą użytkownika. Każda instalacja zaczyna się od administratora [email protected], więc przed włączeniem logowania przenieś je na adres, który kontrolujesz, w sekcji Settings → Account, i włącz tę opcję tylko tam, gdzie nowe konta są akceptowalne, na przykład w aplikacji Google Workspace ograniczonej do Twojej domeny.

Logowanie przez GitHub i Google jest dostępne przez OAuth. Zarejestruj aplikację z adresem wywołania zwrotnego ${PUBLIC_URL}/api/v1/auth/login-callback i dodaj jej poświadczenia:

PUBLIC_URL=https://pentagi.example.com
OAUTH_GITHUB_CLIENT_ID=your_github_client_id
OAUTH_GITHUB_CLIENT_SECRET=your_github_client_secret

Dostępność sieciowa

Domyślnie interfejs webowy PentAGI nasłuchuje tylko na 127.0.0.1. Aby uzyskać do niego dostęp z innych maszyn:

PENTAGI_LISTEN_IP=0.0.0.0
PENTAGI_LISTEN_PORT=8443
PUBLIC_URL=https://192.168.1.100:8443
CORS_ORIGINS=https://localhost:8443,https://192.168.1.100:8443

Użyj prawdziwego adresu w PUBLIC_URL i CORS_ORIGINS, nigdy 0.0.0.0. Utwórz kontenery ponownie poleceniem docker compose up -d --force-recreate i otwórz port 8443 w zaporze.

Za reverse proxy ustaw TRUSTED_PROXIES na adres lub CIDR proxy, oddzielone przecinkami. W przeciwnym razie każde żądanie będzie wyglądać, jakby pochodziło z proxy, a limit logowań na adres — 30 nieudanych prób w ciągu pięciu minut, po których następuje 15-minutowa blokada — będzie współdzielony przez wszystkich użytkowników.

Każdy kontener sandbox flow publikuje również dwa porty do wywołań zwrotnych poza pasmem, takich jak reverse shelle. Pochodzą one z puli 2000 portów zaczynających się od DOCKER_PORTS_BASE (domyślnie 28000) i są powiązane z DOCKER_PUBLIC_IP, adresem, który agenci podają celom do nawiązania połączenia zwrotnego.

Domyślnie DOCKER_PUBLIC_IP to 0.0.0.0: porty nasłuchują na każdym interfejsie hosta Docker, a agenci samodzielnie wyszukują swój publiczny adres. Ustaw konkretny adres tylko wtedy, gdy host go posiada i cele mogą się z nim połączyć; za NAT-em pozostaw domyślne ustawienie. Porty publikowane przez Dockera omijają reguły ufw i firewalld na hoście, więc ogranicz zakres za pomocą zapory sieciowej przed hostem, takiej jak grupa zabezpieczeń w chmurze, lub reguł w łańcuchu DOCKER-USER Dockera.

PROXY_URL kieruje wywołania backendu do providerów modeli, providera embeddingów, API wyszukiwarek oraz sprawdzania aktualizacji przez proxy, co pomaga odizolować instalację od sieci zewnętrznych. Lokalne endpointy, takie jak Ollama, vLLM czy SearXNG, również przechodzą przez to proxy, ponieważ nie ma wyjątku NO_PROXY, więc proxy musi mieć do nich dostęp. Kontenery sandbox flow, w których agenci wykonują swoje polecenia, scraper, który otwiera strony internetowe dla narzędzia przeglądarki, oraz usługa Graphiti nie korzystają z tego proxy, dlatego ogranicz ich ruch wychodzący na poziomie sieci. Logowanie przez GitHub lub Google oraz wywołania endpointu Langfuse lub OpenTelemetry poza dołączonymi stosami również z niego nie korzystają, a demon Docker pobiera obrazy, używając własnych ustawień proxy.

Sprawdzanie aktualizacji

W ciągu dwóch minut od uruchomienia, a następnie co trzy godziny, serwer pyta update.pentagi.com, czy dostępna jest nowsza wersja. Żądanie zawiera identyfikator instalacji, klucz licencyjny (jeśli został ustawiony), wersję i platformę oraz podsumowanie instalacji: skonfigurowanego providera i typy logowania, kilka przełączników funkcji, liczbę użytkowników, flows, tasks, kontenerów, promptów, tokenów API i tool calls, a także sumy tokenów i kosztów według typu providera — bez nazw, adresów, promptów ani zawartości flow. UPDATE_CHECK_INTERVAL=0 wyłącza tę opcję. Przy każdym uruchomieniu instalatora i po każdej wykonanej przez niego akcji, takiej jak Apply Changes, Update, Start lub Stop, wysyłane są zainstalowane obrazy i stan każdego stosu, a gdy PentAGI działa, przesyłane jest również to samo podsumowanie; UPDATE_CHECK_INTERVAL nie ma na to wpływu.

Kontener pentagi działa jako root, ponieważ zarządza kontenerami przez gniazdo Docker. Aby zapewnić silniejszą izolację, uruchom tools na osobnym worker node.

Ostatnia aktualizacja