Hardening Kubernetes dla obciążeń obronnych: wzorce CIS i wytyczne NSA

Kubernetes stał się standardową platformą wdrożeniową dla skonteneryzowanych aplikacji w obronności — od DoD Platform One po krajowe programy chmur obronnych w krajach członkowskich NATO. Jego wdrożenie w środowiskach obronnych jest podyktowane tymi samymi zaletami operacyjnymi, które napędzały adopcję komercyjną: spójne wdrożenie w różnych środowiskach, automatyczne skalowanie, samoleczące się obciążenia i deklaratywne zarządzanie infrastrukturą. Jednak domyślna instalacja Kubernetes jest zaprojektowana pod kątem łatwości użycia, a nie bezpieczeństwa — a różnica między domyślną instalacją a wzmocnionym, obronnym wdrożeniem jest znacząca.

NSA i CISA opublikowały Przewodnik po hardeningu Kubernetes (v1.2, sierpień 2022) specjalnie w celu zaradzenia tej luce. Przewodnik obejmuje wzmacnianie płaszczyzny sterowania, bezpieczeństwo sieci, bezpieczeństwo Pod, rejestrowanie audytu oraz uwierzytelnianie i autoryzację. Wzorzec CIS Kubernetes zapewnia uzupełniający, bardziej szczegółowy zestaw punktowanych kontroli konfiguracji. Razem te dwa dokumenty definiują, co oznacza „wzmocniony" w kontekście Kubernetes w środowisku obronnym.

Przewodnik hardeningu Kubernetes NSA/CISA: kluczowe zalecenia

Przewodnik NSA/CISA organizuje zalecenia w sześciu kategoriach. Najbardziej istotne operacyjnie dla obronności to:

Bezpieczeństwo Pod Kubernetes. Pody powinny używać kontenerów bez uprawnień roota, systemów plików tylko do odczytu i mieć ograniczone możliwości do niezbędnego minimum. Uprzywilejowane kontenery — z pełnym dostępem do systemu hosta — nie mogą być dozwolone w obciążeniach produkcyjnych.

Separacja i wzmacnianie sieci. Cały ruch między usługami powinien być szyfrowany przy użyciu TLS (siatka usług z mTLS). Polityki sieciowe powinny ograniczać komunikację między Podami wyłącznie do jawnie dozwolonych ścieżek. Serwer API Kubernetes nie powinien być bezpośrednio dostępny z internetu.

Uwierzytelnianie i autoryzacja. Serwer API nie może umożliwiać anonimowego uwierzytelniania ani niezabezpieczonych portów. Kontrola dostępu oparta na rolach (RBAC) musi być włączona i skonfigurowana zgodnie z zasadą najmniejszych uprawnień.

Rejestrowanie audytu. Rejestrowanie audytu serwera API musi być włączone z polityką rejestrującą co najmniej operacje tworzenia, aktualizacji, usuwania i pobierania na wrażliwych typach zasobów. Dzienniki audytu muszą być przekazywane do centralnego SIEM.

Częstotliwość aktualizacji. Wersje Kubernetes otrzymują poprawki bezpieczeństwa przez około 14 miesięcy po wydaniu. Uruchamianie nieobsługiwanych wersji Kubernetes stanowi znaczące ryzyko bezpieczeństwa, niedopuszczalne w wdrożeniach obronnych.

Standardy bezpieczeństwa Pod: profil Restricted

Standardy bezpieczeństwa Pod (PSS) Kubernetes definiują trzy profile polityki — Privileged, Baseline i Restricted — reprezentujące rosnące poziomy restrykcji konfiguracji Pod. Profil Restricted jest odpowiednim punktem wyjścia dla obciążeń obronnych: wymusza najbardziej istotne z punktu widzenia bezpieczeństwa ograniczenia konfiguracji Pod.

Profil Restricted nie zezwala na: uprzywilejowane kontenery, kontenery działające jako root (wymuszane przez runAsNonRoot: true), kontenery uzyskujące dostęp do sieci hosta, kontenery uzyskujące dostęp do PID lub IPC hosta, kontenery montujące ścieżki hosta jako woluminy oraz kontenery dodające możliwości Linux spoza zdefiniowanej listy dozwolonych.

Wdrożenie profilu Restricted w istniejącym środowisku Kubernetes często wymaga zmian aplikacji. W przypadku nowego tworzenia aplikacji obronnych zgodność z profilem Restricted powinna być wymaganiem projektowym od samego początku.

Standardy bezpieczeństwa Pod są egzekwowane przez wbudowany kontroler admisji PodSecurity. Wdrożenia obronne powinny używać trybu Enforce dla profilu Restricted we wszystkich przestrzeniach nazw produkcyjnych.

Polityki sieciowe: mikrosegmentacja z Calico lub Cilium

Polityki sieciowe Kubernetes definiują, które Pody mogą komunikować się z innymi Podami na poziomie IP/portu. Bez Polityk sieciowych wszystkie Pody w klastrze mogą komunikować się ze wszystkimi innymi Podami — płaska topologia sieciowa architektonicznie niezgodna z zasadami zero-trust. Polityki sieciowe implementują warstwę mikrosegmentacji na poziomie sieci kontenerów.

Calico jest najszerzej stosowaną implementacją polityki sieciowej Kubernetes, obsługującą zarówno standardowe zasoby NetworkPolicy Kubernetes, jak i zasoby specyficzne dla Calico z dodatkowymi możliwościami. Dla środowisk air-gapped model wdrożenia lokalnego Calico i brak zależności od chmurowej płaszczyzny sterowania sprawiają, że jest on operacyjnie odpowiedni.

Cilium używa eBPF do egzekwowania polityki sieciowej w jądrze Linux, zapewniając wyższą wydajność niż rozwiązania oparte na iptables i obsługując polityki sieciowe Warstwy 7. Komponent obserwowalności Hubble firmy Cilium zapewnia szczegółową widoczność przepływów sieciowych.

Kluczową zasadą projektowania Polityki sieciowej w obronności jest domyślne odmawianie: nowe przestrzenie nazw powinny mieć domyślną NetworkPolicy blokującą cały ruch przychodzący i wychodzący do momentu tworzenia jawnych reguł zezwolenia.

Kontrolery admisji: Policy-as-Code z OPA/Gatekeeper i Kyverno

Kontrolery admisji to wtyczki przechwytujące żądania serwera API przed ich utrwaleniem w etcd, umożliwiające egzekwowanie polityk na poziomie API klastra. OPA/Gatekeeper i Kyverno to dwa dominujące frameworki policy-as-code dla kontroli admisji Kubernetes.

OPA/Gatekeeper używa silnika polityk OPA z językiem polityk Rego. Gatekeeper rejestruje się jako ValidatingAdmissionWebhook wywołujący silnik polityk OPA dla każdego odpowiedniego żądania API. Szablony ograniczeń definiują strukturę polityki; Ograniczenia tworzą instancje szablonu dla konkretnych zasobów.

Kyverno używa natywnego YAML Kubernetes do wyrażania polityk, co czyni go bardziej dostępnym dla zespołów znających definicje zasobów Kubernetes. Kyverno obsługuje zarówno walidację (blokowanie niezgodnych zasobów), jak i mutację (automatyczne dodawanie wymaganych etykiet lub pól kontekstu bezpieczeństwa do zasobów).

W przypadku wdrożeń obronnych polityki kontroli admisji powinny wymuszać co najmniej: pochodzenie obrazów (obrazy muszą pochodzić z zatwierdzonych rejestrów), podpisywanie obrazów (obrazy muszą mieć ważne podpisy cosign), wymagania dotyczące kontekstu bezpieczeństwa, wymagane etykiety i limity zasobów.

Bezpieczeństwo środowiska wykonawczego: Falco, seccomp i AppArmor

Falco (CNCF-graduated) to standardowe narzędzie bezpieczeństwa środowiska wykonawczego dla Kubernetes: monitoruje wywołania systemowe jądra w czasie rzeczywistym i generuje alerty, gdy zachowanie odpowiada podejrzanym wzorcom. Reguły Falco obejmują wykonywanie procesów, dostęp do plików, aktywność sieciową i aktywność API Kubernetes. Falco integruje się z systemami SIEM poprzez wyjście syslog lub Webhook.

seccomp (secure computing mode) Profile ograniczają wywołania systemowe dostępne dla procesów kontenerów. Kubernetes zapewnia domyślny profil seccomp (RuntimeDefault) blokujący najbardziej niebezpieczne wywołania systemowe. Obciążenia obronne powinny używać co najmniej profilu RuntimeDefault.

AppArmor (w dystrybucjach Linux, które go obsługują) zapewnia warstwę obowiązkowej kontroli dostępu ograniczającą dostęp każdego procesu do plików, możliwości i operacji sieciowych. Profile AppArmor dla kontenerów Kubernetes dodają warstwę obrony w głąb.