Bezpieczeństwo Kubernetes: RBAC, zasady sieciowe i bezpieczeństwo podów

Kubernetes orkiestruje obciążenia uruchamiane w kontenerach na dużą skalę, ale jego złożoność tworzy rozległą powierzchnię ataku. Do kluczowych komponentów, które należy zabezpieczyć, należą: API Server (centralny element płaszczyzny sterowania — jego przejęcie daje kontrolę nad całym klastrem), etcd (baza danych stanu klastra — przechowuje sekrety w formacie base64, dlatego muszą być szyfrowane w spoczynku), kubelet (agent węzła — nieuwierzytelnione API kubeleta umożliwia dowolne uruchamianie podów), container runtime (Docker/containerd) oraz infrastruktura sieciowa łącząca wszystkie pody. Osoby przygotowujące się do egzaminu Security+ powinny rozumieć, że błędne konfiguracje Kubernetes należą do najczęściej wykrywanych problemów bezpieczeństwa w chmurze.

RBAC (Role-Based Access Control) w Kubernetes określa, którzy użytkownicy, konta usług i procesy mogą wykonywać określone działania na określonych zasobach API. Model obejmuje cztery obiekty: Role (uprawnienia w zakresie przestrzeni nazw), ClusterRole (uprawnienia obowiązujące w całym klastrze), RoleBinding (przyznaje rolę podmiotowi w obrębie przestrzeni nazw) oraz ClusterRoleBinding (przyznaje ClusterRole podmiotowi w całym klastrze). Każde polecenie kubectl jest tłumaczone na wywołanie API, które jest sprawdzane względem reguł RBAC. Jeśli RBAC nie jest skonfigurowany, każdy uwierzytelniony użytkownik (lub konto usługi) może mieć uprawnienia administracyjne.

Każdy pod w Kubernetes działa w kontekście konta usługi — tożsamości używanej do uwierzytelniania względem API. Domyślnie pody korzystają z konta usługi default w swojej przestrzeni nazw, które może mieć szerokie uprawnienia. Zasada najmniejszych uprawnień wymaga tworzenia dedykowanych kont usług dla każdej aplikacji i przyznawania im wyłącznie uprawnień, których potrzebują. Ponadto ustawienie automountServiceAccountToken: false dla podów, które nie wymagają dostępu do API, zapobiega zamontowaniu tokenu konta usługi w systemie plików poda, gdzie przejęta aplikacja mogłaby użyć go do wykonywania wywołań API.

Domyślnie w Kubernetes wszystkie pody mogą komunikować się ze wszystkimi innymi podami w dowolnej przestrzeni nazw. Przejęty pod może natychmiast próbować uzyskać dostęp do baz danych, wewnętrznych interfejsów API i innych mikrousług. Zasoby Kubernetes NetworkPolicy definiują reguły ograniczające ruch między podami na podstawie etykiet, przestrzeni nazw i portów. Zalecanym podejściem jest zastosowanie zasady sieciowej „domyślnie odmów wszystko” w każdej przestrzeni nazw, a następnie dodanie jawnych reguł zezwalających na wymagane ścieżki komunikacji. Należy pamiętać, że NetworkPolicy wymaga wtyczki CNI, która ją obsługuje (Calico, Cilium, Weave) — standardowy Kubernetes ignoruje NetworkPolicy bez zgodnej wtyczki CNI.

Pod Security Standards (PSS), wprowadzone w Kubernetes 1.23 i uznane za stabilne w wersji 1.25, zastępują wycofaną funkcję Pod Security Policy (PSP) trzema wbudowanymi profilami egzekwowanymi na poziomie przestrzeni nazw: Privileged (bez ograniczeń, przeznaczony dla komponentów systemowych), Baseline (zapobiega znanym eskalacjom uprawnień, takim jak kontenery uprzywilejowane i dostęp do sieci hosta) oraz Restricted (zaostrzony, wymaga użytkowników innych niż root, usuwa wszystkie capabilities i wymusza używanie głównych systemów plików tylko do odczytu). Przestrzenie nazw oznacza się etykietami w celu wymuszenia poziomu zasad, a pody, które je naruszają, są odrzucane podczas admission.

Secrets w Kubernetes przechowują poufne dane, takie jak hasła, tokeny i certyfikaty TLS. Domyślnie sekrety są przechowywane w etcd jako wartości zakodowane w base64 — nie są szyfrowane. Każdy, kto może odczytać etcd lub ma odpowiednie uprawnienia RBAC, może je łatwo zdekodować. Najlepsze praktyki obejmują: włączenie szyfrowania danych w spoczynku w etcd za pomocą AES-GCM z kluczem przechowywanym w KMS (AWS KMS, GCP KMS), integrację z zewnętrznym menedżerem sekretów, takim jak HashiCorp Vault lub AWS Secrets Manager, za pośrednictwem Secrets Store CSI Driver, oraz ograniczenie dostępu do Secretów za pomocą RBAC, tak aby mogły je odczytywać wyłącznie konta usług, które ich potrzebują.

Kontrolery admission to wtyczki serwera API Kubernetes, które przechwytują żądania API po uwierzytelnieniu i autoryzacji, ale przed zapisaniem obiektu. Dzięki temu mogą weryfikować, modyfikować lub odrzucać żądania. Do kontrolerów admission związanych z bezpieczeństwem należą: PodSecurity (wymusza standardy bezpieczeństwa podów), ImagePolicyWebhook (umożliwia zewnętrzną weryfikację podpisów obrazów), AlwaysPullImages (wymusza każdorazowe pobieranie obrazów, aby uniemożliwić użycie lokalnie zbuforowanych złośliwych obrazów) oraz OPA/Gatekeeper (Open Policy Agent — najbardziej elastyczne rozwiązanie, umożliwiające definiowanie niestandardowych zasad w języku Rego w celu egzekwowania dowolnych reguł bezpieczeństwa organizacji).

Wzmacnianie zabezpieczeń komponentów płaszczyzny sterowania Kubernetes ma kluczowe znaczenie: serwer API powinien używać --anonymous-auth=false w celu wyłączenia nieuwierzytelnionego dostępu, mieć skonfigurowaną opcję --audit-log-path do rejestrowania całej aktywności API oraz używać TLS dla wszystkich połączeń. kubelet powinien mieć ustawioną opcję --authorization-mode=Webhook (a nie AlwaysAllow) oraz wyłączone uwierzytelnianie anonimowe. etcd powinien używać szyfrowania TLS komunikacji między węzłami i z klientami, mieć ograniczony dostęp sieciowy (dostęp powinien mieć wyłącznie serwer API) oraz szyfrować dane w spoczynku. CIS Kubernetes Benchmark zawiera kompleksową listę kontrolną wszystkich ustawień komponentów.

Przestrzenie nazw Kubernetes zapewniają logiczne rozdzielenie zasobów, ale same w sobie nie stanowią silnej granicy bezpieczeństwa — zapewniają przede wszystkim izolację organizacyjną. Rzeczywista izolacja środowiska wielodostępnego (np. obciążeń należących do różnych klientów) wymaga dodatkowych mechanizmów: zasad sieciowych blokujących ruch między przestrzeniami nazw, limitów zasobów zapobiegających atakom DoS powodowanym przez nadmierne zużycie zasobów przez jednego użytkownika, oddzielnych pul węzłów dla silnie izolowanych dzierżawców lub dedykowanego klastra dla każdego dzierżawcy. Wiele organizacji korzysta z Hierarchical Namespaces lub komercyjnych rozwiązań, takich jak vCluster, aby zapewnić silniejszą wielodostępność w ramach jednego klastra.

Rejestrowanie audytowe Kubernetes rejestruje każde żądanie API: kto je wysłał, skąd pochodziło, jakie działanie zażądano wykonać i jakiego zasobu dotyczyło. Dzienniki audytowe są niezbędne do prowadzenia dochodzeń kryminalistycznych po incydencie bezpieczeństwa oraz wykrywania anomalnego zachowania, takiego jak nietypowe powiązania ról, dostęp do sekretów czy polecenia exec wykonywane w produkcyjnych podach. Dzienniki audytowe należy przesyłać strumieniowo do scentralizowanego systemu SIEM. Falco zapewnia monitorowanie zachowania kontenerów w czasie wykonywania, natomiast zarządzane przez dostawców chmurowe usługi Kubernetes (EKS, GKE, AKS) zapewniają natywną integrację dzienników audytowych z odpowiednimi platformami rejestrowania.

Bezpieczeństwo łańcucha dostaw w Kubernetes zapewnia, że do środowiska produkcyjnego trafiają wyłącznie zaufane i zweryfikowane obrazy. Zalecenia CNCF dotyczące bezpieczeństwa łańcucha dostaw obejmują: weryfikowanie podpisów obrazów za pomocą Cosign przed wdrożeniem (wymuszane przez kontrolery admission), generowanie i weryfikowanie SBOM (Software Bills of Materials) dla wszystkich obrazów kontenerów w celu śledzenia pochodzenia komponentów, przypinanie obrazów do digestów (myimage@sha256:abc123) zamiast zmiennych tagów oraz skanowanie wszystkich zewnętrznych chartów Helm pod kątem błędnych konfiguracji i podatności przed wdrożeniem.

W tej lekcji poznali Państwo następujące zagadnienia: Kubernetes RBAC kontroluje dostęp do API za pomocą obiektów Role, ClusterRole i Binding — w przypadku kont usług zawsze należy stosować zasadę najmniejszych uprawnień; konfiguracje NetworkPolicy z domyślną odmową zapobiegają przemieszczaniu się zagrożeń między podami i przestrzeniami nazw; a Pod Security Standards wymuszają wzmacnianie zabezpieczeń kontenerów na poziomie przestrzeni nazw, blokując uprzywilejowane kontenery, dostęp do sieci hosta i uruchamianie jako root. Następnie omówimy bezpieczeństwo serverless oraz powierzchnie ataku na poziomie funkcji.