Bezpieczeństwo Kubernetes: od czego zacząć

Kubernetes stał się domyślnym sposobem uruchamiania aplikacji w chmurze i na własnej infrastrukturze. Daje elastyczność, ale też dużą, złożoną powierzchnię ataku: klaster to sieć, tożsamości, sekrety i obrazy w jednym. W testach najczęściej widzimy te same błędy — i od nich warto zacząć hardening.

Najczęstsze błędy konfiguracji

Zbyt szeroki RBAC. Konta serwisowe i użytkownicy z uprawnieniami cluster-admin „żeby działało” sprawiają, że przejęcie jednego poda daje kontrolę nad klastrem. To ten sam grzech nadmiarowych uprawnień, co w chmurze.
Brak polityk sieciowych. Domyślnie każdy pod może rozmawiać z każdym. Bez NetworkPolicy przejęty kontener swobodnie porusza się po klastrze.
Sekrety w jawnej postaci. Hasła i tokeny w zmiennych środowiskowych, manifestach czy repozytorium git zamiast w menedżerze sekretów.
Nadmierne przywileje podów. Kontenery uruchamiane jako root, z privileged, dostępem do hosta czy socketa Dockera — to gotowa droga ucieczki z kontenera.
Odsłonięty panel i API. Publicznie dostępne API serwera lub dashboard bez silnego uwierzytelniania.

Priorytety hardeningu

Ogranicz RBAC do najmniejszych uprawnień — osobne konta serwisowe per aplikacja, żadnego cluster-admin „na zapas”.
Wdróż polityki sieciowe z domyślną odmową i jawnie dozwolonym ruchem między usługami.
Wymuś standardy bezpieczeństwa podów (Pod Security Standards): brak roota, brak trybu privileged, tylko niezbędne capabilities.
Zarządzaj sekretami poza manifestami (zewnętrzny menedżer, szyfrowanie w etcd).
Zabezpiecz obrazy — skanowanie podatności, zaufane rejestry, podpisy; to część łańcucha dostaw.

Nie zapomnij o monitoringu

Hardening to nie wszystko — potrzebujesz też widoczności. Włącz audit log API serwera, zbieraj logi i alertuj na podejrzane działania (tworzenie kont o wysokich uprawnieniach, uruchamianie podów privileged, nietypowe exec do kontenerów). Dobrym punktem odniesienia jest CIS Kubernetes Benchmark, ale — jak przy hardeningu Linuksa — stosuj go ze zrozumieniem, a nie na ślepo.

Jeśli chcesz sprawdzić, jak odporny jest Twój klaster i jak daleko zaszedłby atakujący po przejęciu jednego poda, umów test.

Granice odpowiedzialności w klastrze

Bezpieczeństwo Kubernetes obejmuje control plane, węzły, workloady, obrazy, tożsamości i zależności chmurowe. W usłudze zarządzanej dostawca może utrzymywać control plane, ale organizacja nadal odpowiada za RBAC, workloady, sekrety, sieć i konfigurację integracji. Zapisz ten podział jawnie dla każdego klastra.

Używaj osobnych kont i krótkotrwałych poświadczeń dla ludzi, CI/CD i workloadów. Nie stosuj grupy system:masters po bootstrapie. ServiceAccount powinno mieć osobne uprawnienia dla konkretnego zadania, a automatyczne montowanie tokenu należy wyłączyć tam, gdzie pod go nie potrzebuje.

Pod Security Standards i polityka admission

Profil Restricted ogranicza najbardziej ryzykowne ustawienia, takie jak privileged, host namespaces, niebezpieczne capabilities i uruchamianie jako root. Sam dokument standardu nie egzekwuje konfiguracji — potrzebujesz wbudowanego Pod Security Admission lub innego kontrolera polityki. Najpierw uruchom tryb audit/warn, usuń wyjątki, a dopiero później enforce.

Każdy wyjątek ma właściciela, zakres namespace i termin wygaśnięcia. Bez tego „tymczasowy” privileged pod staje się stałą ścieżką do węzła.

Sekrety, etcd i ruch sieciowy

Kubernetes Secrets nie są magicznym sejfem. Kontroluj RBAC do odczytu, włącz szyfrowanie danych w spoczynku dla etcd, ogranicz dostęp do kopii i rozważ zewnętrzny menedżer sekretów. Nie umieszczaj sekretów w obrazie, ConfigMap ani logu.

NetworkPolicy działa tylko z obsługującym ją pluginem sieciowym. Zweryfikuj to testem. Zacznij od default deny ingress i egress, następnie dodaj minimalne przepływy DNS, zależności aplikacji i observability. Monitoruj próby połączeń, aby polityka nie była wyłącznie plikiem w repozytorium.

Dowody zdrowego klastra

Raport powinien łączyć wynik konfiguracji z testem: kto może tworzyć pod, kto może wykonać exec, czy pod osiąga API metadanych, czy token jest montowany oraz czy reguła sieciowa rzeczywiście blokuje ruch. Po zmianie wersji Kubernetes lub CNI powtórz testy regresyjne.

Źródła: Kubernetes Security Checklist, Kubernetes Pod Security Standards, Kubernetes Secrets good practices, CIS Kubernetes Benchmark.