Kubernetes między enklawami bezpieczeństwa: klastry wieloklauzulowe

Programy obronne rzadko działają na pojedynczym poziomie klauzuli. To samo oprogramowanie misyjne, które przyjmuje źródła otwarte w enklawie Unclassified, często ma wariant Secret łączący je z wrażliwym zbieraniem, a czasem wariant Top Secret na dodatek. Instynkt inżyniera przyzwyczajonego do komercyjnego Kubernetes każe modelować te poziomy jako przestrzenie nazw, najemców lub klastry wirtualne w obrębie jednej platformy. Ten instynkt jest błędny w pracy niejawnej, a naprawa błędu jest kosztowna. W środowisku wielopoziomowym bezpiecznym (MLS) klaster Kubernetes — i sieć, w której się znajduje — jest granicą klauzuli, a nie szczegółem wielodostępności wewnątrz niej. Ten artykuł omawia, jak uruchamiać Kubernetes między enklawami bezpieczeństwa: jeden akredytowany klaster na poziom klauzuli, ścisła izolacja polityk wewnątrz każdego, weryfikowalne pochodzenie obrazów oraz kontrolowane, jednokierunkowe awansowanie artefaktów między domenami.

Granicą jest klaster, a nie przestrzeń nazw

Kubernetes daje kilka mechanizmów wyglądających jak izolacja: przestrzenie nazw, NetworkPolicies, RBAC, kwoty zasobów i kontrolę dopuszczania. Każdy z nich to mechanizm wielodostępności działający wewnątrz jednej granicy zaufania. Wszystkie współdzielą ten sam serwer API, ten sam magazyn etcd, to samo jądro Linuksa na każdym węźle i to samo środowisko uruchomieniowe kontenerów. Ucieczka z kontenera przez podatność jądra, błąd w ścieżce autoryzacji serwera API lub jedno zbyt szerokie ClusterRoleBinding mogą przekroczyć wszystkie te miękkie granice naraz.

Akredytator patrzący na system MLS zadaje proste pytanie: co fizycznie lub kryptograficznie powstrzymuje dane Secret przed dotarciem na stronę Unclassified? „NetworkPolicy” nie jest akceptowalną odpowiedzią, ponieważ NetworkPolicy jest wymuszana przez ten sam wtyczkę CNI i jądro, na których działają same obciążenia. Akceptowalną odpowiedzią jest oddzielenie: osobne klastry, osobne sieci, osobny sprzęt lub osobne kryptograficznie izolowane partycje, każda akredytowana do przetwarzania dokładnie jednego poziomu. Przestrzenie nazw pozostają przydatne — ale tylko jako przedziały administracyjne w obrębie jednej enklawy, nigdy jako linia między Unclassified a Secret.

To ta sama zasada, która leży u podstaw rozwiązań międzydomenowych dla obronności: dane przemieszczają się między poziomami tylko przez akredytowanego strażnika, nigdy przez współdzielony element sterowania programowego, do którego mają dostęp obie strony. Kubernetes z wieloma enklawami po prostu stosuje tę zasadę do warstwy orkiestracji.

Jeden klaster na enklawę: topologia wzorcowa

Topologia wzorcowa dla programu trójpoziomowego to trzy w pełni niezależne wdrożenia Kubernetes, po jednym na enklawę:

Enklawa Unclassified / deweloperska. Tu odbywa się większość prac inżynierskich. Ma najszerszą łączność (często ścieżkę do internetu przez serwer proxy do pobierania zależności z góry), najbardziej liberalny rytm zmian i potok budowania wytwarzający artefakty, które wyższe enklawy ostatecznie spożytkują. Wciąż jest utwardzona — sieć typu default-deny, podpisane obrazy, brak uprzywilejowanych podów — ale jest jedyną enklawą, w której rodzą się nowe obrazy.

Enklawa Secret. Odłączony od publicznego internetu, ten klaster uruchamia wariant Secret oprogramowania misyjnego. Pobiera obrazy tylko z własnego rejestru w enklawie, który jest zasilany wyłącznie przez awansowanie z dołu. Jego rytm zmian jest wolniejszy, a każde wdrożenie jest powiązane z akredytowanym wydaniem. Dyscyplina operacyjna przypomina tu wdrożenie Kubernetes odizolowane od sieci — rejestry offline, brak żywych pobrań z góry i proces aktualizacji, który musi przetrwać akredytację.

Enklawa Top Secret. Najbardziej ograniczony klaster, w najbardziej izolowanej sieci, z najsurowszymi kontrolami personelu i fizycznymi. Otrzymuje wyselekcjonowany podzbiór artefaktów ze strony Secret, znowu tylko przez akredytowany transfer.

Każda enklawa to kompletny, samowystarczalny wszechświat Kubernetes: własna płaszczyzna sterowania i etcd, własne CNI i klasy magazynowe, własny rejestr obrazów, własny dostawca tożsamości i RBAC, własny kontroler GitOps oraz własny stos obserwowalności. Nic w wyższej enklawie nie zależy od dostępności usługi w niższej enklawie w czasie wykonania. To właśnie ta niezależność pozwala akredytować każdy klaster na własnych warunkach.

Dlaczego federacja między poziomami to kanał ukryty

Kuszącym skrótem jest sfederowanie tożsamości, dystrybucji obrazów lub GitOps między enklawami, aby operatorzy mieli jedną konsolę. Oprzyj się temu. Żywa federacja uwierzytelniania wydająca token użyteczny zarówno po stronie Unclassified, jak i Secret jest z definicji kanałem czasu rzeczywistego między dwoma poziomami — dokładnie tym, czemu oddzielenie ma zapobiegać. Obecność lub brak udanego logowania, czas odświeżania tokenów, a nawet kody błędów mogą kodować informacje przez granicę. Ta sama logika wyklucza współdzielony rejestr, do którego piszą obie strony, lub pojedynczy kontroler GitOps uzgadniający klastry na różnych poziomach. Wszystko, co utrzymuje synchroniczne połączenie przez granicę, jest potencjalnym kanałem ukrytym i nie przejdzie przeglądu.

Izolacja polityk wewnątrz każdej enklawy

Oddzielenie między enklawami jest konieczne, ale niewystarczające. Wewnątrz każdego klastra wciąż potrzebujesz rygorystycznego podziału na przedziały, ponieważ enklawa hostuje wiele obciążeń, usług i zespołów, które nie powinny swobodnie sięgać do siebie nawzajem. To tutaj natywne kontrole Kubernetes zarabiają na swoje miejsce.

Zacznij od kontroli dopuszczania. Silnik polityk taki jak Kyverno lub OPA Gatekeeper wymusza nienegocjowalne reguły w momencie dopuszczania obciążenia: uruchomić mogą się tylko podpisane obrazy z własnego rejestru enklawy; żaden pod nie może żądać trybu uprzywilejowanego, sieci hosta ani montowania ścieżek hosta; każdy kontener działa jako użytkownik non-root z systemem plików głównym tylko do odczytu i zredukowanym zestawem uprawnień; a każda przestrzeń nazw spełnia ograniczony profil Pod Security Standards. To te same kontrole utwardzania omówione szczegółowo w artykule utwardzanie Kubernetes dla obciążeń obronnych, zastosowane identycznie w każdej enklawie, tak aby linia bazowa nie dryfowała między poziomami.

Sieć wewnątrz enklawy działa na zasadzie default-deny. Każda przestrzeń nazw zaczyna się od NetworkPolicy odrzucającej cały ruch przychodzący i wychodzący, a łączność jest przyznawana jawnie dla każdej pary usług. Ruch wschód-zachód między wrażliwymi przedziałami przechodzi przez wzajemny TLS, zazwyczaj przez siatkę usług, tak aby dostęp kontrolowała tożsamość obciążenia — a nie tylko jego pozycja w sieci. Kwoty zasobów i zakresy limitów zapobiegają wygłodzeniu klastra przez pojedyncze skompromitowane lub błędne obciążenie.

RBAC i dyscyplina break-glass

RBAC wewnątrz każdej enklawy bez wyjątku przestrzega najmniejszych uprawnień. Codzienni operatorzy otrzymują role ograniczone do przestrzeni nazw; nikt nie posiada stałego cluster-admin. Uprawnienie cluster-admin żyje za procedurą break-glass: poświadczenie, które jest zapieczętowane, którego użycie wyzwala alert i którego każde działanie jest zapisywane do niezmiennego magazynu audytu. Ponieważ enklawy są niezależne, procedura break-glass również jest niezależna — użycie jej w enklawie Secret nie daje niczego w enklawie Unclassified. Konta usług są ograniczone do jednej przestrzeni nazw, ich tokeny są krótkotrwałe i powiązane z konkretnym obciążeniem, a żadne z nich nigdy nie jest ponownie używane między klastrami.

Pochodzenie obrazów: zaufanie zdobyte przy budowaniu, zweryfikowane przy uruchomieniu

W architekturze z wieloma enklawami łańcuch dostaw jest najbardziej atrakcyjną powierzchnią ataku, ponieważ obraz zbudowany raz po stronie niskiej może ostatecznie działać na poziomie Top Secret. Każdy obraz musi zatem nieść weryfikowalne pochodzenie, które najwyższa enklawa może sprawdzić bez ufania jakiejkolwiek niższej enklawie w czasie wykonania.

Dyscyplina jest taka: buduj w najniższej enklawie zdolnej zbudować obraz, generuj kompletny wykaz komponentów oprogramowania (SBOM) w formacie SPDX lub CycloneDX, skanuj go względem bazy danych podatności odbitej do tej enklawy i podpisuj zarówno obraz, jak i SBOM kluczem Sigstore Cosign. Podpis wiąże skrót obrazu ze znanym procesem budowania. Każda enklawa ma własny rejestr — Harbor i zot to częste wybory dla pracy odłączonej — a kontroler dopuszczania każdego klastra weryfikuje podpis Cosign względem klucza publicznego specyficznego dla enklawy przed dopuszczeniem obrazu do uruchomienia. Niepodpisany obraz lub taki, którego skrót nie odpowiada awansowanemu wpisowi, nigdy się nie uruchamia.

Ma to znaczenie przez granicę, ponieważ klaster po stronie wysokiej nie ufa rejestrowi po stronie niskiej; ufa kryptograficznemu podpisowi i skrótowi zarejestrowanemu podczas awansowania. Nawet gdyby rejestr po stronie niskiej został skompromitowany po awansowaniu obrazu, strona wysoka odrzuciłaby każdy zamiennik, którego skrót różni się od zarejestrowanego.

Kontrolowane awansowanie między domenami

Awansowanie to jedyny usankcjonowany sposób, w jaki artefakt przekracza granicę enklawy, i jest ściśle jednokierunkowe z niskiego do wysokiego poziomu. Ścieżka przebiega przez akredytowane rozwiązanie międzydomenowe lub, dla najsurowszych łączy, sprzętową diodę danych, która fizycznie zezwala na transfer tylko w jednym kierunku.

Strażnik transferu wykonuje prawdziwą pracę, a nie tylko kopiowanie. Waliduje skrót obrazu i podpis Cosign względem listy dozwolonych zatwierdzonych artefaktów; inspekcjonuje SBOM i odrzuca każdy obraz zawierający zabroniony komponent, niezatwierdzoną licencję lub znany podatny pakiet powyżej progu programu; usuwa lub normalizuje metadane, które mogłyby nieść ukryte dane; oraz rejestruje transfer z tożsamością operatora, znacznikiem czasu i skrótem artefaktu do zapisu audytu po obu stronach. Dopiero po przejściu każdej kontroli artefakt jest zapisywany do rejestru po stronie wysokiej, skąd wysoki klaster może go pobrać.

Przemieszczanie z wysokiego do niskiego poziomu to niebezpieczny kierunek i jest traktowane odpowiednio. Pobieranie dzienników, metryk lub telemetrii budowania w dół z enklawy Secret do Unclassified to potencjalny wyciek, więc jest albo wprost zabronione, albo kierowane przez osobny, znacznie surowszy przegląd z ludzkim orzeczeniem co do każdego wydanego rekordu. Domyślną postawą jest to, że dane płyną w górę i tam pozostają.

GitOps i operacje bez przekraczania linii

Każda enklawa ma własny kontroler GitOps — Argo CD lub Flux — uzgadniający względem repozytorium Git, które żyje wewnątrz tej enklawy. Manifesty stanu pożądanego dla wyższej enklawy same są artefaktami awansowanymi w górę przez rozwiązanie międzydomenowe, przeglądanymi tak samo jak obrazy. To zachowuje ślad audytu (repozytorium po stronie wysokiej rejestruje dokładnie to, co zostało awansowane i przez kogo) bez łączenia kontrolera przez granicę.

Obserwowalność przestrzega tej samej reguły. Falco do wykrywania zagrożeń w czasie wykonania, dziennik audytu Kubernetes, metryki Prometheus i scentralizowane dzienniki kontenerów — wszystkie działają wewnątrz każdej enklawy i zasilają lokalny SIEM enklawy. Telemetria nigdy nie jest strumieniowana z wysokiej enklawy na pulpit po stronie niskiej; jeśli połączony, międzypoziomowy obraz operacyjny jest naprawdę potrzebny, buduje się go przez eksport zweryfikowanych podsumowań w górę do najwyższej enklawy, a nie przez pobieranie surowej telemetrii w dół. Retencja audytu jest ustawiana dla każdej enklawy zgodnie z jej wymogiem akredytacji, a ciągłe monitorowanie — ponowne skany podatności względem lustra w enklawie, wykrywanie dryfu, okresowa ponowna weryfikacja podpisów obrazów — działa niezależnie w każdym klastrze.

Ile to kosztuje i dlaczego jest tego warte

Uruchamianie trzech niezależnych klastrów zamiast jednego wielodostępnego to naprawdę więcej pracy: trzy płaszczyzny sterowania do łatania, trzy rejestry do zasilania, trzech dostawców tożsamości, trzy potoki GitOps i proces awansowania między nimi. Inżynierowie odczuwają tarcie za każdym razem, gdy obraz, który działa po stronie niskiej, musi zostać awansowany, zanim będzie mógł działać wyżej. Ale to tarcie jest właściwością bezpieczeństwa, a nie jego wadą. Bramka awansowania to miejsce, gdzie weryfikuje się pochodzenie, wyłapuje zabronione komponenty i tworzy kompletny, niezmienny zapis tego, co przekroczyło granicę. Zwinięcie enklaw w jeden klaster dla oszczędności wysiłku oznaczałoby wymianę akredytowanej, możliwej do obrony architektury na pojedyncze współdzielone jądro i serwer API stojące między Unclassified a Secret — wymianę, której nie zaakceptuje żaden akredytator i której nie powinien chcieć żaden program.

Dla zespołów, które muszą również utrzymywać wyższe enklawy odłączone, wzorce operacyjne naturalnie łączą się z praktyką Kubernetes odizolowaną od sieci: rejestry offline, odbite zależności i dyscyplina aktualizacji, która nie zakłada żywej ścieżki do świata zewnętrznego.