Strona deployment-modes odpowiada „który tryb i gdzie leżą dane". Ta strona odpowiada „jak to uruchomić w praktyce": jakie są wymagania per tryb, jakie kroki wykonuje onboarding, jakie zmienne środowiskowe/sekrety istnieją w kodzie i jak sprawdzić, że instancja żyje. Dziś operacyjnie dowodliwy jest jeden tryb — SaaS EU (LIVE). Kroki dla trybów izolowanych (private tenant / VPC / on-prem) są oznaczone jawnie jako ROADMAP.
Onboarding w trybie SaaS EU nie wymaga od klienta uruchamiania własnej infrastruktury — konto, autoryzacja JWT i konektory importu działają na instancji zarządzanej przez K0NSULT. Zmienne środowiskowe i flagi opisane niżej są dziś przede wszystkim materiałem do przeglądu bezpieczeństwa (co istnieje w kodzie, co jest domyślnie wyłączone) — a docelowo podstawą konfiguracji trybów self-hosted (private tenant / VPC / on-prem).
Tabela pokazuje, co musi dostarczyć klient, a co dostarcza K0NSULT. Szczegóły trybów (dla kogo, gdzie dane) → deployment-modes.
| Tryb | Status | Po stronie klienta | Po stronie K0NSULT |
|---|---|---|---|
| SaaS EU | LIVE | Dostęp HTTPS wychodzący do k0nsult.cloud; konto/token JWT; brak wymogu instalacji. |
Hosting (Fly.io, region fra — Frankfurt, EU), PostgreSQL, sekrety, monitoring, health-checki, backupy. |
| Private tenant | ROADMAP | Brak — dedykowana instancja nadal po stronie K0NSULT. Zależy od dojrzałości izolacji tenantów. | Osobna baza/środowisko per klient w regionie UE. Wymaga domknięcia IP3_TENANT_SCOPE (patrz sekcja env). |
| Customer VPC | ROADMAP | Konto chmurowe (region wg wymogu), sieć/subnet, PostgreSQL 14+ (managed lub własny), sekret-manager, reverse proxy z TLS. | Obraz kontenera (Dockerfile w repo), skrypt migracji (npm run migrate), wsparcie wdrożeniowe. |
| On-prem / air-gapped | ROADMAP | Cała infrastruktura: serwer/kontener runtime, PostgreSQL, TLS/mTLS, monitoring, proces rotacji sekretów, ewentualny offline-mirror CVE. | Obraz + dokumentacja instalacji; brak dostępu operacyjnego K0NSULT do środowiska klienta. |
Sekwencja odzwierciedla realny kontrakt API /api/ip3/v1 (JWT/RBAC, PostgreSQL). Nazwy endpointów — jak w kodzie repozytorium.
POST /api/ip3/v1/auth/login → zwraca {token, roles} (JWT). Token używany jako Bearer we wszystkich kolejnych wywołaniach.POST /api/ip3/v1/imports/burp|zap|nessus|csv|generic|qualys|re — parsują wynik skanera/RE na incydenty + evidence (bez wykonywania skanów/eksploatacji).POST /api/ip3/v1/engagements, wpisy .../log, raport .../final-report (wymaga evidence-register — claim ≤ proof, egzekwowane kodem 422).GET /api/ip3/v1/reports/evidence-package/{id} (JSON lub PDF) — manifest + package_sha256 + chain-of-custody.GET /api/ip3/v1/incidents/{id}/legal-triggers — mapowanie DORA/NIS2/RODO/AI Act; wynik to wsparcie decyzji, nie porada prawna — wymaga przeglądu prawnika/DPO przed wysyłką do organu.Nazwy zmiennych — dokładnie jak w kodzie (server.js, routes/ip3-*.js). W trybie SaaS EU klient ich nie ustawia — konfiguruje i rotuje je K0NSULT. Tabela służy dziś przeglądowi bezpieczeństwa, a docelowo — konfiguracji trybów self-hosted.
| Zmienna | Wymagane | Domyślnie | Do czego służy |
|---|---|---|---|
DATABASE_URL | tak | brak | Connection string PostgreSQL — bez niej operacje ipIII zwracają 503 (kod: brak DB). |
JWT_SECRET | tak | brak | Klucz podpisu tokenów JWT (auth v1, routes/ip3-api-pro.js). |
JWT_EXPIRES | nie | wartość w kodzie | Czas ważności tokena JWT. |
PG_CONNECT_TIMEOUT_MS | nie | wartość w kodzie | Timeout połączenia z PostgreSQL. |
PORT / HOST | nie | 8080 (zgodnie z fly.toml) | Port/adres nasłuchu procesu Node. |
NODE_ENV | nie | — | Tryb środowiska (production/development) — wpływa m.in. na logowanie. |
IP3_SEED_PASS | nie | brak (fallback dev/staging) | Hasło konta seedowego. Human-only: rotacja/wyłączenie przed każdym wdrożeniem poza pilotem. |
IP3_TENANT_SCOPE | nie | off | Flaga izolacji wielodostępnej (scoping po org_id, warstwa aplikacji). Dziś off w SaaS EU — ROADMAP dla trybów izolowanych, patrz known-limitations. |
IP3_OIDC (+ _JWKS_URI/_ISSUER/_AUDIENCE/_ROLES_CLAIM) | nie | off | Flaga walidacji OIDC/JWKS równolegle z JWT-legacy (off|shadow|on). Dziś off — self-service SSO to ROADMAP. |
IP3_AUDIT_CHAIN + IP3_SIGNING_KEY | nie | off | Flaga łańcucha hash audytu z kluczem podpisującym (off|shadow|on). Dziś off w domyślnym wdrożeniu. |
IP3_WEBHOOK_URL / IP3_WEBHOOK_SECRET | nie | brak | Transport wychodzący zdarzeń (webhook) do systemu klienta. |
GITHUB_TOKEN / GITHUB_ISSUES_REPO | nie | brak | Konektor remediacji do GitHub Issues (flaga IP3_GITHUB_TRANSPORT). |
JIRA_BASE_URL / JIRA_USER / JIRA_TOKEN / JIRA_PROJECT_KEY | nie | brak | Konektor remediacji do Jira (flaga IP3_JIRA_TRANSPORT). |
JWT_SECRET, IP3_SIGNING_KEY,
tokeny GitHub/Jira, hasła seedowe), zarządzanie nimi w sekret-managerze oraz przegląd bezpieczeństwa przed
wdrożeniem trybu self-hosted wymagają inżyniera bezpieczeństwa/DevSecOps po stronie odbiorcy lub K0NSULT —
ta strona opisuje nazwy i przeznaczenie zmiennych, nie dostarcza gotowych wartości ani nie zastępuje przeglądu.
Trzy publiczne endpointy diagnostyczne — bez ujawniania danych wrażliwych. Wszystkie LIVE.
| Endpoint | Metoda | Auth | Zwraca |
|---|---|---|---|
/health | GET | brak (rate-limit 30/15min) | Ogólny stan aplikacji (poza warstwą ipIII). |
/api/health | GET | brak | {ok:true, status:'healthy'} — dokładnie ten endpoint jest celem health-checku w fly.toml. |
/api/ip3/v1/_health | GET | brak | {ok:true, layer:'ip3/v1', db:<bool>, note:'PostgreSQL LIVE'|'brak DB (503 dla operacji)'} — potwierdza, czy warstwa ipIII ma żywe połączenie z bazą. |
Konfiguracja health-checku wdrożenia (z fly.toml): ścieżka /api/health, interwał 30s, timeout 5s, grace period 60s, port 8080. Region główny fra (Frankfurt, UE) — potwierdza deklarację „dane w regionie UE" z deployment-modes.
IP3_OIDC, IP3_TENANT_SCOPE i
IP3_AUDIT_CHAIN istnieją w repozytorium (kod przechodzi testy w trybie shadow/on),
ale w domyślnym wdrożeniu SaaS EU są off. Traktujemy je jako ROADMAP
dopóki nie są włączone i zweryfikowane w produkcyjnej konfiguracji — zgodnie z known-limitations.
Powiązane: tryby wdrożenia i suwerenność danych → /deployment-modes · rejestr znanych ograniczeń → /known-limitations · kontrole bezpieczeństwa → /security-pack · model wielodostępności → /tenant-model.