Kubernetes dla obciążeń obronnych: orkiestracja niejawnych aplikacji kontenerowych

Orkiestracja kontenerów stała się dominującym wzorcem wdrożeń w nowoczesnym oprogramowaniu obronnym, jednak wymagania operacyjne środowisk niejawnych nakładają ograniczenia, których standardowe konfiguracje Kubernetes nie spełniają domyślnie. Typowy klaster uruchamiany przez kubeadm udostępnia nieuwierzytelnione API kubelet, przechowuje sekrety w postaci jawnej w etcd, nie stosuje żadnych polityk sieciowych między podami i generuje dzienniki audytu, które nie są ani przekazywane dalej, ani chronione przed manipulacją. Każde z tych ustawień domyślnych to ustalenie w każdym poważnym przeglądzie bezpieczeństwa. W artykule omówiono, co jest potrzebne, aby uruchomić Kubernetes prawidłowo w środowisku niejawnym: od hartowania węzłów według wzorców CIS i STIG, przez zarządzanie sekretami oparte na HSM, mikrosegmentację sieci, architekturę dzienników audytu, kontrolę łańcucha dostaw obrazów, aż po dokumentację niezbędną do uzyskania Upoważnienia do Działania.

Dlaczego orkiestracja kontenerów ma znaczenie dla nowoczesnego wdrażania oprogramowania obronnego

Oprogramowanie obronne było historycznie wdrażane jako monolityczne aplikacje na dedykowanych serwerach fizycznych, a każda aktualizacja systemu wymagała ręcznej koordynacji w wielu domenach bezpieczeństwa i obszernego ponownego testowania, zanim jakakolwiek zmiana trafiała do środowiska operacyjnego. Orkiestracja kontenerów odwraca ten model: aplikacje są pakowane jako niezmienne obrazy, infrastruktura jest deklarowana jako kod, a orkiestrator zarządza harmonogramem, sprawdzaniem stanu i aktualizacjami stopniowymi w całej flocie węzłów. Dla programów, które muszą dostarczać aktualizacje możliwości operatorom w tygodniach, a nie latach, ta zmiana nie jest opcjonalna.

Kubernetes zapewnia dodatkowe korzyści szczególnie istotne dla obciążeń niejawnych. Izolacja zasobów na poziomie przestrzeni nazw pozwala wielu aplikacjom o tym samym poziomie klasyfikacji współdzielić infrastrukturę węzłów bez wzajemnego zakłócania zasobów CPU, pamięci czy sieci. Limity zasobów zapobiegają temu, by nieprawidłowo działające obciążenie pochłonęło całą pojemność klastra. Budżety zakłóceń podów wymuszają ograniczenia dostępności podczas okien serwisowych. Mechanizmy te bezpośrednio odpowiadają wymaganiom niezawodności i izolacji, które urzędnicy autoryzujący oczekują ujrzeć w Planie Bezpieczeństwa Systemu.

Wyzwaniem jest to, że projekt Kubernetes jest zaprojektowany dla komercyjnych środowisk chmurowych skierowanych do internetu, a jego domyślna konfiguracja odzwierciedla to dziedzictwo. Programy obronne adoptujące Kubernetes muszą traktować konfigurację domyślną jako punkt wyjścia do hartowania, a nie akceptowalny punkt bazowy. Luka między domyślnym klastrem a klastrem gotowym do akredytacji jest znaczna, lecz jest dobrze udokumentowana przez DISA i Center for Internet Security, i można ją zlikwidować celową pracą konfiguracyjną.

Hartowanie węzłów: zgodność z benchmarkiem CIS i STIG dla węzłów roboczych Kubernetes

Hartowanie węzłów zaczyna się na warstwie systemu operacyjnego, zanim zostanie zainstalowany jakikolwiek komponent Kubernetes. Węzły robocze powinny być budowane z obrazu bazowego zahartowanego zgodnie ze STIG lub CIS Poziom 2 -- Red Hat Enterprise Linux CoreOS (RHCOS) dla klastrów opartych na OpenShift lub zahartowany Ubuntu lub Rocky Linux dla upstream Kubernetes. Konfiguracja bazowego systemu operacyjnego obejmuje partycjonowanie systemu plików (oddzielne montowania /tmp, /var, /var/log), hartowanie parametrów jądra (wyłączenie przekierowania IP z wyjątkiem przypadków wymaganych przez CNI, włączenie syncookies, wyłączenie trasowania źródłowego IP), obowiązkową kontrolę dostępu (tryb wymuszania SELinux lub profile AppArmor) oraz usunięcie zbędnych pakietów i usług.

Na warstwie Kubernetes STIG DISA dla Kubernetes i benchmark CIS Kubernetes Poziom 2 zbiegają się na podstawowym zestawie wymagań konfiguracyjnych kubeletu. Port kubeletu tylko do odczytu musi być wyłączony (--read-only-port=0). Uwierzytelnianie anonimowe musi być wyłączone (--anonymous-auth=false). Tryb autoryzacji musi być ustawiony na Webhook, delegując wszystkie decyzje autoryzacyjne do silnika RBAC serwera API, a nie ufając lokalnym decyzjom węzła. Rotacja certyfikatów musi być włączona, aby certyfikaty klienta kubelet były odnawiane automatycznie przed wygaśnięciem. Środowisko uruchomieniowe kontenerów -- containerd lub CRI-O -- musi być skonfigurowane z domyślnym profilem seccomp (RuntimeDefault) stosowanym do wszystkich podów, chyba że wymagają one bardziej liberalnego lub niestandardowego profilu.

Uruchomienie kube-bench, audytora benchmarku CIS o otwartym kodzie źródłowym, na skonfigurowanym klastrze generuje ustrukturyzowany raport zgodności w formacie XCCDF. Raport ten jest wymaganym załącznikiem w większości pakietów akredytacyjnych. Ustalenia Kategorii I (wysokiego ryzyka) muszą być usunięte przed złożeniem; ustalenia Kategorii II powinny być usunięte lub udokumentowane z kompensującymi środkami kontroli. Zautomatyzowane playbooki remediacyjne -- Ansible lub podobne -- stosujące mechanizmy kontrolne benchmarku w sposób powtarzalny na wszystkich węzłach są zdecydowanie preferowane nad ręczną konfiguracją, zarówno dlatego, że zmniejszają dryft konfiguracji, jak i dlatego, że generują audytowalne zapisy zmian.

Egzekwowanie polityk sieciowych: mikrosegmentacja między niejawnymi obciążeniami

Domyślnie wszystkie pody w klastrze Kubernetes mogą komunikować się ze wszystkimi innymi podami, niezależnie od przestrzeni nazw. Ten model płaskiej sieci jest odpowiedni dla środowisk deweloperskich, ale niedopuszczalny dla obciążeń niejawnych, gdzie zasada minimalnych uprawnień musi dotyczyć ruchu sieciowego tak samo jak uprawnień RBAC. Egzekwowanie segmentacji sieci wymaga dwóch rzeczy: wtyczki CNI implementującej specyfikację NetworkPolicy Kubernetes oraz zestawu obiektów NetworkPolicy definiujących dozwolone ścieżki komunikacji.

Bazowy wzorzec hartowania to polityka domyślnego zakazu (default-deny-all) stosowana do każdej przestrzeni nazw podczas inicjalizacji klastra. Polityka ta zabrania całego ruchu przychodzącego i wychodzącego, chyba że jawna reguła zezwolenia na to pozwala. Jawne reguły zezwolenia są następnie dodawane dla każdej wymaganej ścieżki ruchu: rozwiązywanie DNS (TCP i UDP port 53 do CoreDNS w kube-system), ruch kontroli stanu od kubeletu do kontenerów aplikacji oraz specyficzna dla aplikacji komunikacja między usługami. Każda reguła zezwolenia powinna być ograniczona jak najbardziej precyzyjnie -- przez selektor etykiet podów, selektor etykiet przestrzeni nazw i port -- zamiast używania szerokich zakresów CIDR, które przejdą kontrolę audytora, ale nie ograniczą w rzeczywistości przemieszczania się bocznego.

Dla obciążeń działających na różnych poziomach klasyfikacji, które muszą współistnieć na współdzielonej infrastrukturze, sama polityka NetworkPolicy oparta na etykietach jest niewystarczająca. Wtyczka CNI egzekwuje polityki w warstwie netfilter jądra Linux, a wystarczająco uprzywilejowany skompromitowany kontener może ominąć netfilter. Programy obronne hostujące obciążenia na wielu poziomach wrażliwości w jednym klastrze powinny umieszczać każdy poziom wrażliwości w dedykowanej puli węzłów z dedykowanymi interfejsami sieciowymi lub sieciami VLAN i egzekwować kontrole ruchu między poziomami na warstwie sprzętowej lub hiperwizora. Architektura połączeń chmury obronnej zapewnia fizyczną i logiczną separację, której same mechanizmy kontrolne oparte na politykach nie mogą zagwarantować na współdzielonej infrastrukturze jądra.

Zarządzanie sekretami: integracja Kubernetes z magazynami kluczy opartymi na HSM

Sekrety Kubernetes są domyślnie przechowywane w etcd jako wartości kodowane w base64 bez szyfrowania. Każdy użytkownik lub proces z dostępem do odczytu w etcd -- lub z wystarczającymi uprawnieniami RBAC do wywołania kubectl get secret -- może odczytać wartość w postaci jawnej. Dla środowisk niejawnych nie jest to luka w konfiguracji; to fundamentalny problem architektoniczny, który musi być rozwiązany, zanim jakiekolwiek wrażliwe dane zostaną zapisane w klastrze. Rozwiązaniem jest szyfrowanie danych w spoczynku w etcd przy użyciu dostawcy KMS, który deleguje zarządzanie kluczami do magazynu kluczy opartego na HSM.

Zasób EncryptionConfiguration kube-apiserver określa listę dostawców szyfrowania dla każdego typu zasobu. Dla dostawcy kms konfiguracja wskazuje na gniazdo Unix, gdzie nasłuchuje proces wtyczki KMS. Wtyczka tłumaczy protokół gRPC KMS Kubernetes na wywołania HSM lub usługi zarządzania kluczami -- zazwyczaj przez PKCS#11 dla sieciowego HSM lub przez API zarządzania kluczami obronnej chmury. Gdy serwer API zapisuje sekret do etcd, wywołuje wtyczkę KMS w celu zaszyfrowania klucza szyfrowania danych (DEK) kluczem szyfrowania klucza (KEK) przechowywanym w HSM. W etcd przechowywany jest wyłącznie opakowany DEK razem z szyfrogramem. Odszyfrowanie wymaga komunikacji z HSM. HSM musi posiadać walidację FIPS 140-2 Poziom 3 dla obciążeń na poziomie TAJNY; Poziom 2 jest ogólnie akceptowalny tylko dla materiałów WRAŻLIWYCH, lecz NIENIEJAWNYCH.

Rejestrowanie zdarzeń audytowych: rejestrowanie zdarzeń serwera API dla zgodności i kryminalistyki

Serwer API Kubernetes generuje dziennik audytu każdego przetwarzanego żądania: kto je wysłał, jaki czasownik i zasób był zaangażowany, jaka przestrzeń nazw, czy żądanie się powiodło oraz -- w zależności od skonfigurowanego poziomu audytu -- pełna treść żądania i odpowiedzi. Ten dziennik jest autorytatywnym zapisem do odpowiedzi na pytanie "kto co zrobił w tym klastrze i kiedy". Dla środowisk niejawnych kompleksowe rejestrowanie audytowe nie jest opcjonalne; jest konkretnym wymaganiem kontrolnym w RMF, JSIG i równoważnych ramach, a brak odpowiednich dzienników audytu jest zazwyczaj ustaleniem blokującym podczas przeglądu akredytacyjnego.

Polityka audytu to plik YAML przekazywany do kube-apiserver podczas uruchamiania, który mapuje typy zasobów i czasowniki na poziomy audytu. Cztery poziomy to: None (brak rejestrowania), Metadata (użytkownik, czasownik, zasób, status -- bez treści), Request (dodaje treść żądania) i RequestResponse (dodaje zarówno treść żądania, jak i odpowiedzi). Polityka spełniająca wymagania zgodności rejestruje RequestResponse dla Sekretów, ConfigMap, Ról, Powiązań Ról, Ról Klastra, Powiązań Ról Klastra i Kont Serwisowych -- zasobów, których modyfikacja mogłaby wskazywać na eskalację uprawnień lub kradzież poświadczeń. Wywołania exec i attach podów muszą być również rejestrowane na poziomie RequestResponse, gdyż są podstawowymi wektorami interaktywnego przemieszczania się bocznego w skompromitowanym klastrze. Wszystkie pozostałe zasoby mogą być rejestrowane na poziomie Metadata, co zapewnia kompletny zapis dostępów bez kosztów pamięci masowej związanych z rejestrowaniem każdego ładunku aplikacji.

Dzienniki audytu przechowywane wyłącznie na węźle płaszczyzny sterowania są podatne na manipulację ze strony skompromitowanego administratora klastra. Architektura audytu klasy obronnej przesyła dzienniki do zewnętrznego miejsca docelowego, do którego sam klaster nie może zapisywać ani usuwać: systemu SIEM (systemu zarządzania informacjami i zdarzeniami bezpieczeństwa), magazynu obiektów kompatybilnego z S3 tylko do dołączania z retencją blokady obiektów lub dedykowanego systemu przekierowania syslog do powietrzno-izolowanej infrastruktury agregacji dzienników. Moduł przesyłania dzienników -- DaemonSet Fluentd lub Fluent Bit na węzłach płaszczyzny sterowania -- musi działać z kontem serwisowym Kubernetes bez uprawnień do obiektów klastra, które są rejestrowane, aby skompromitowany moduł nie mógł zatrzeć własnych śladów przez modyfikację polityki audytu lub usunięcie plików dziennika.

Skanowanie obrazów i bezpieczeństwo łańcucha dostaw w niejawnych rejestrach kontenerów

Każdy obraz kontenera wdrożony w niejawnym klastrze jest potencjalną powierzchnią ataku na łańcuch dostaw. Obraz pobrany z publicznego rejestru bez kontroli może zawierać znane podatne wersje bibliotek, osadzone poświadczenia lub złośliwy kod wprowadzony podczas potoku kompilacji. Programy obronne muszą obsługiwać prywatny rejestr kontenerów odizolowany od publicznego internetu, wymagający uwierzytelnionego dostępu i wymuszający skanowanie podatności oraz podpisywanie obrazów przed dopuszczeniem jakiegokolwiek obrazu do klastra.

Narzędzia do skanowania podatności obrazów, takie jak Trivy lub Grype, analizują każdą warstwę obrazu w odniesieniu do bazy danych doradztw OSV i biuletynów bezpieczeństwa dostawców, generując listę CVE z ocenami ważności i wersjami zagrożonych pakietów. W niejawnym potoku CI skanowanie odbywa się w ramach procesu budowania obrazu; obrazy zawierające CVE o ważności Krytycznej lub Wysokiej są blokowane przed przesłaniem do rejestru produkcyjnego do czasu usunięcia podatności lub formalnego przyjęcia ich jako ryzyka. Wyniki skanowania są przechowywane razem z obrazem w metadanych rejestru i przywoływane w pakiecie dowodów akredytacyjnych jako dowód, że inwentaryzacja oprogramowania jest znana i przeglądana.

Podpisywanie obrazów dodaje kryptograficzne potwierdzenie, że określony skrót obrazu został wyprodukowany przez określony potok kompilacji i nie został zmodyfikowany od czasu podpisania. Narzędzie cosign projektu Sigstore obsługuje podpisywanie kluczem przechowywanym w HSM lub KMS, generując atestację podpisu przechowywaną w rejestrze razem z obrazem. Webhook dopuszczający Kubernetes -- używający silnika polityk takiego jak Kyverno lub OPA Gatekeeper -- weryfikuje podpis przed zaplanowaniem jakiegokolwiek poda. Ten łańcuch nadzoru od kompilacji do wdrożenia to dokładnie to, czego wymagają ramy bezpieczeństwa łańcucha dostaw: każde obciążenie uruchomione w klastrze można powiązać z konkretnym podpisanym artefaktem kompilacji, a niepodpisane lub zmanipulowane obrazy są odrzucane na warstwie dopuszczania, a nie odkrywane podczas kryminalistycznego przeglądu po incydencie.

Ścieżka akredytacji: przeprowadzanie klastra Kubernetes przez ATO lub odpowiednik

Upoważnienie do Działania (ATO) dla klastra Kubernetes to nie pojedynczy dokument, lecz pakiet dowodów zebranych w celu wykazania, że system spełnia mechanizmy kontrolne bezpieczeństwa określone w obowiązujących ramach -- Risk Management Framework (RMF) dla programów federalnych USA, JSIG dla wspólnych systemów wywiadowczych lub odpowiedniki programowe dla zaopatrzenia obronnego sojuszniczych krajów. Urzędnik autoryzujący przegląda ten pakiet i podejmuje decyzję o akceptacji ryzyka. Zrozumienie, co musi zawierać pakiet, jest niezbędne do planowania harmonogramu akredytacji, ponieważ luki odkryte późno w procesie przeglądu mogą opóźnić wdrożenie o miesiące.

Plan Bezpieczeństwa Systemu jest dokumentem centralnym. Dla klastra Kubernetes SSP musi opisywać architekturę klastra (liczba i rozmieszczenie węzłów płaszczyzny sterowania, topologia etcd, pule węzłów roboczych, topologia sieci), konfigurację hartowania węzłów z odniesieniami do raportu zgodności kube-bench, konfigurację szyfrowania etcd, model RBAC (które konta serwisowe mają jakie uprawnienia i dlaczego), architekturę polityk sieciowych, proweniencję obrazów i łańcuch podpisywania oraz architekturę przekazywania dzienników audytu. Każdy mechanizm kontrolny w obowiązującym punkcie bazowym jest albo spełniony (z odniesieniem do dowodów), nie ma zastosowania (z uzasadnieniem) lub otwarty (z kompensującym środkiem kontroli lub wpisem w POA&M).

Ciągłe monitorowanie jest warunkiem większości ATO, a nie jednorazowym progiem. Klaster musi być zarejestrowany w systemie zarządzania konfiguracją, który wykrywa dryft od zahartowanego punktu bazowego, procesie zarządzania podatnościami, który śledzi CVE w wdrożonych obrazach i pakietach systemu operacyjnego węzłów według SLA remediacji, oraz procesie przeglądu dzienników monitorującym zdarzenia audytowe pod kątem anomalii. Zautomatyzowane narzędzia -- kube-bench zaplanowany jako Kubernetes CronJob, ponowne skanowanie obrazów według nocnego harmonogramu, reguły alertowania SIEM dla podejrzanych wzorców serwera API -- generują dowody ciągłego monitorowania bez wymagania ręcznego wysiłku przy każdym cyklu przeglądu. Programy, które budują tę automatyzację przed złożeniem pierwszego wniosku ATO, są w znacznie silniejszej pozycji przy ponownej autoryzacji niż te, które traktują ciągłe monitorowanie jako działanie podejmowane po udzieleniu autoryzacji.