Integracja i wdrożenie
OmegaOS™ Kernel jest wdrażany jako overlay na Państwa istniejącej infrastrukturze.
Brak konieczności migracji. Z reguły brak zmian w kodzie aplikacji. Rejestracja dowodów od pierwszego dnia.
Overlay, nie zamiennik
OmegaOS™ Kernel nie zastępuje Państwa identity providera, API gateway ani Policy Decision Point (PDP). Otacza je. Tworzy jednolitą warstwę dowodową, w której każda autoryzacja jest ewaluowana, rejestrowana i weryfikowalna.
Państwa istniejący PDP działa nadal jak dotychczas. OmegaOS™ Kernel rejestruje decyzje, dodaje trójwartościową ewaluację i generuje eksportowalne Evidence Packs (pakiety dowodowe).
- Klasyfikacja
- Suwerenna infrastruktura decyzyjna. Overlay dla infrastruktury autoryzacji.
- Funkcja
- Rejestruje decyzje autoryzacyjne z pełnym łańcuchem dowodów. Eksportuje pakiety dowodowe z hashami integralności SHA-256 i opcjonalną atestacją Ed25519 (jeśli dostarczone są klucze podpisywania).
- Relacja
- Otacza Państwa istniejący PDP (OPA, Cedar, rozwiązanie własne). Dodaje rejestrację dowodów i trójwartościowe wykrywanie konfliktów.
- Wdrożenie
- Overlay. Brak zastępowania istniejących systemów. Brak zmian w kodzie aplikacyjnym; mogą być potrzebne dostosowania bramki lub routingu.
Architektura overlay
OmegaOS™ Kernel łączy się z Państwa istniejącym stosem. Nie zastępuje — otacza.
Brak konieczności migracji. OmegaOS™ Kernel najpierw obserwuje Państwa istniejące przepływy autoryzacji. Rejestruje co decyduje Państwa obecny system. Gdy będziesz gotowy, wprowadza ewaluację trójwartościową obok — nie zamiast — Państwa istniejącego PDP. Mogą być wymagane dostosowania okablowania bramki i routingu w Państwa wdrożeniu.
Tryb shadow
Porównuj decyzje OmegaOS™ Kernel z Państwa istniejącym PDP w czasie rzeczywistym. Identyfikuj rozbieżności przed egzekwowaniem.
Wykrywanie rozbieżności (mismatch)
W trybie shadow bramka przekierowuje każde żądanie zarówno do Państwa upstream PDP, jak i do silnika rozstrzygania OmegaOS™ Kernel. Zwraca werdykt Państwa PDP do klienta — bez zakłóceń — ale rejestruje oba wyniki i oznacza ewentualne rozbieżności.
Rozbieżności są liczone w metrykach Prometheus (upstream_del_mismatches) i uwzględniane w odpowiedzi decyzyjnej. Daje to precyzyjny pomiar dywergencji przed przejściem do trybu enforce (egzekwowanie).
| Metryka | Znaczenie |
|---|---|
| Match | PDP i OmegaOS™ Kernel zgodne w wyniku |
| Mismatch | PDP i OmegaOS™ Kernel nie zgodne — oznaczone do przeglądu |
| Conflict | OmegaOS™ Kernel wykrył sprzeczne dowody (Indeterminate) |
Domyślne fail-closed
Gdy system nie jest w stanie zewaluować, odmawia. Bez cichego przepuszczania.
OPA nieosiągalny
Gdy upstream PDP jest nieosiągalny w trybie enforce, bramka zwraca 403 Forbidden. Decyzje nie są zgadywane. Awaria jest logowana z pełnym kontekstem.
Konfigurowalny tryb awaryjny
Tryb awaryjny jest zarządzany przez politykę OPA_FAIL_MODE. Domyślnie: closed. W trybie closed każdy błąd blokuje żądanie. W trybie open (niezalecany w produkcji) błędy są logowane, ale dostęp jest przyznawany.
Advisory-only z założenia
OmegaOS™ Kernel dostarcza ustrukturyzowane decyzje informujące operatorów ludzkich. Nie wykonuje autonomicznych działań downstream. W trybach observe i shadow działa wyłącznie doradczo. W trybie enforce routuje werdykty dostępowe (200/403/409) i powierza wykonanie logiki biznesowej wywołującej aplikacji.
Wzorce integracji
Trzy wzorce wdrożenia. Brak zmian w aplikacji.
| Wzorzec | Opis |
|---|---|
| Sidecar | Wdróż bramkę jako kontener sidecar. Kieruj wywołania autoryzacyjne na localhost:3200. Natywne dla Kubernetes. |
| Reverse proxy | Umieść bramkę przed API. Kompatybilne z nginx auth_request, Envoy ext_authz lub dowolnym proxy z obsługą subrequestów. |
| Równoległy pipeline | Uruchom tryb shadow obok istniejącego systemu. Porównanie w czasie rzeczywistym podczas testów. Eskalacja egzekwowania po potwierdzeniu wyników. |
Konfiguracja
Przełączanie trybów dostępne przez zmienne środowiskowe. Wszystko realizowane jako zmiana pojedynczej zmiennej dla wdrożenia zero-downtime.
Rollback to jedna zmienna. Ustaw GATEWAY_MODE=observe, aby powrócić do trybu samej rejestracji. Zazwyczaj restart nie jest wymagany. Dane są zachowywane.
OmegaOS™ — Overlay suwerenności
OmegaOS™ rozszerza OmegaOS™ Kernel o warstwę suwerenności jako overlay — jednostkę governance, która otacza całą Państwa architekturę IT ujednoliconą powłoką decyzyjną.
Kernel i Decision Evidence Log (DEL) są już operacyjne. Warstwa governance multi-engine — w tym granice zaufania między silnikami oraz reguły propagacji decyzji — jest w fazie implementacji.
OmegaOS™ nie jest samodzielnym systemem operacyjnym. Funkcjonuje jako wykonawcza warstwa nadzorcza. Nie wypiera Państwa struktury — organizuje sposób, w jaki dane autoryzacyjne przez nią przepływają.
OmegaOS™ Kernel = warstwa governance wykonawczego (evidence runtime)
OmegaOS™ = overlay suwerenności (powłoka sterująca dla OS / K8s / cloud)
Dowód z założenia
OmegaOS™ Kernel nie prosi o zaufanie systemowi. Generuje dowód, aby mogli Państwo go zweryfikować. Każda decyzja, każdy dowód, każdy eksport — zarejestrowany, identyfikowalny, reprodukowalny.