# Bezpieczeństwo

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

## [Zmień ustawienia domyślne](https://pentagi.com/pl/docs/configuration/security/#change-the-defaults)

Świeża instalacja tworzy lokalnego administratora `admin@pentagi.com` 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 `admin@pentagi.com`.

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:

| Zmienna                                              | Przeznaczenie                                                                                         |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| `COOKIE_SIGNING_SALT`                                | Podpisuje ciasteczka sesji i tokeny API — ustaw losową wartość                                        |
| `PENTAGI_POSTGRES_USER`, `PENTAGI_POSTGRES_PASSWORD` | Poświadczenia PostgreSQL                                                                              |
| `NEO4J_PASSWORD`                                     | Hasło Neo4j do [knowledge graph](https://pentagi.com/pl/docs/glossary/#knowledge-graph); `NEO4J_USER` musi pozostać `neo4j` |
| `PUBLIC_URL`                                         | Adres 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](https://pentagi.com/pl/docs/configuration/security/#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](https://pentagi.com/pl/docs/configuration/security/#users-and-sign-in)

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 `admin@pentagi.com`, 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:

```bash
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](https://pentagi.com/pl/docs/configuration/security/#network-exposure)

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

```bash
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](https://pentagi.com/pl/docs/glossary/#sandbox) [flow](https://pentagi.com/pl/docs/glossary/#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](https://pentagi.com/pl/docs/configuration/security/#update-check)

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](https://pentagi.com/pl/docs/glossary/#task), kontenerów, promptów, tokenów API i [tool calls](https://pentagi.com/pl/docs/glossary/#tool-call), 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.

> [!WARNING]
> Kontener `pentagi` działa jako root, ponieważ zarządza kontenerami przez gniazdo Docker. Aby zapewnić silniejszą izolację, uruchom [tools](https://pentagi.com/pl/docs/glossary/#tool) na osobnym [worker node](https://pentagi.com/pl/docs/deployment/worker-node/).