Kubernetes nie rozwiązuje problemów z bezpieczeństwem aplikacji—dodaje jedynie warstwę orkiestracji na ich szczycie. Każdy klaster wprowadza płaszczyznę sterowania (control plane), środowisko wykonawcze węzła (node runtime), model tożsamości, programowo definiowaną sieć (software-defined network) oraz magazyn sekretów (secrets store), z których każdy ma swoje własne tryby awarii. Pojedyncze zbyt liberalne RoleBinding lub jeden pod z privileged: true może przekształcić błąd webowy o niskiej wadze w pełne przejęcie klastra, a stamtąd w kompromitację konta chmurowego, które za nim stoi.
Ten przewodnik omawia, jak faktycznie testować środowisko Kubernetes: powierzchnię ataku, błędne konfiguracje, które pojawiają się niemal w każdym audycie, wektory ucieczki z kontenera, które zamieniają skompromitowany pod w roota na węźle, oraz jak trzy dyscypliny—skanowanie obrazów (image scanning), testowanie środowiska wykonawczego (runtime testing) i Penetration Testing klastra—łączą się ze sobą.
Powierzchnia Ataku Kubernetes
Zanim rozpoczniesz testowanie, zmapuj to, co widzi atakujący. Klaster Kubernetes udostępnia cztery cenne komponenty, a każdy z nich stanowi odrębny cel z własnymi trybami awarii.
Serwer API
kube-apiserver to drzwi wejściowe do wszystkiego. Każde polecenie kubectl, każdy kontroler, każde obciążenie, które komunikuje się z klastrem, przechodzi przez niego. Testowanie serwera API oznacza sprawdzenie, czy dostęp anonimowy jest wyłączony, czy uwierzytelnianie jest wymuszane (a nie tylko autoryzacja RBAC za otwartymi drzwiami), czy flagi --anonymous-auth=false i audit-logging są ustawione oraz czy punkt końcowy nie jest niepotrzebnie wystawiony na publiczny internet. Zaskakująca liczba klastrów zarządzanych i samodzielnie hostowanych nadal pozostawia serwer API dostępnym z dowolnego miejsca, jedynie z ochroną opartą na tokenach.
Kubelet
Każdy węzeł uruchamia kubelet, który udostępnia API (domyślny port 10250) do zarządzania podami na tym węźle. Jeśli kubelet zezwala na nieuwierzytelniony lub tylko do odczytu dostęp (starszy port 10255), atakujący, który dotrze do węzła—lub pod, który może do niego routować—może wyliczyć uruchomione pody, odczytać ich środowisko, a w błędnie skonfigurowanych klastrach wykonywać polecenia wewnątrz kontenerów. Kubelet to klasyczny punkt zwrotny, który jest sondowany przez kube-hunter.
etcd
etcd to baza danych klastra. Przechowuje każdy obiekt, w tym Secrets, w postaci jawnej, chyba że szyfrowanie w spoczynku (encryption at rest) jest jawnie włączone. Bezpośredni dostęp do etcd jest równoznaczny z uprawnieniami cluster-admin: możesz odczytać każde poświadczenie i przepisać stan klastra. Testowanie weryfikuje, że etcd jest dostępne tylko z płaszczyzny sterowania (control plane), wymaga wzajemnego TLS i ma skonfigurowane --encryption-provider-config, tak aby Secrets nie znajdowały się w postaci jawnej.
RBAC i tożsamość
Kontrola dostępu oparta na rolach (Role-based access control) to tkanka łączna. Decyduje o tym, które podmioty mogą mieć dostęp do jakich zasobów. Ponieważ RBAC jest addytywny i łatwo jest przyznać zbyt szerokie uprawnienia, jest to najczęstsze źródło ścieżek eskalacji uprawnień w rzeczywistych klastrach—omówione szczegółowo poniżej.
Typowe Błędne Konfiguracje Klastra
Zwrot błędna konfiguracja bezpieczeństwa klastra Kubernetes obejmuje przewidywalny zestaw wzorców. Są to ustalenia, które pojawiają się niemal w każdej pierwszej ocenie, uszeregowane w przybliżeniu według częstotliwości, z jaką prowadzą do rzeczywistego naruszenia bezpieczeństwa.
Pody uprzywilejowane i z nadmiernymi możliwościami
Pod z securityContext.privileged: true ma faktycznie nieograniczony dostęp do hosta. Nawet bez pełnych uprawnień, niebezpieczne możliwości, takie jak CAP_SYS_ADMIN, allowPrivilegeEscalation: true, lub uruchamianie jako UID 0, dają atakującemu znacznie więcej, niż wymaga tego obciążenie. Rozwiązaniem jest restrykcyjny kontekst bezpieczeństwa zastosowany wszędzie:
Montowanie hostPath i współdzielone przestrzenie nazw
Wolumin hostPath montuje katalog z węzła do poda. Zamontowanie /, /var/run/docker.sock lub /etc/kubernetes pozwala kontenerowi na odczyt lub zapis w systemie plików hosta—to natychmiastowa ucieczka. To samo dotyczy hostPID, hostNetwork i hostIPC, które naruszają granicę izolacji między podem a węzłem. Testowanie oznacza każde obciążenie żądające tych uprawnień, chyba że istnieje udokumentowany i audytowany powód (na przykład CNI lub DaemonSet monitorujący).
Domyślne tokeny konta usługi
Domyślnie każdy pod otrzymuje token konta usługi default przestrzeni nazw zamontowany pod adresem /var/run/secrets/kubernetes.io/serviceaccount/token. Jeśli to konto usługi ma jakiekolwiek znaczące uprawnienia RBAC—lub jeśli obciążenie w ogóle nie potrzebuje dostępu do API—token staje się darmowym materiałem uwierzytelniającym dla każdego, kto przejmie poda. Ustaw automountServiceAccountToken: false dla obciążeń, które nie wywołują API, i odpowiednio ogranicz zakres tych, które to robią.
Brakujące NetworkPolicies
Domyślnie sieć Kubernetes jest płaska: każdy pod może dotrzeć do każdego innego poda w dowolnej przestrzeni nazw. Bez NetworkPolicies, pojedynczy skompromitowany pod front-endowy może komunikować się bezpośrednio z Twoją bazą danych, wewnętrznymi usługami administracyjnymi i punktem końcowym metadanych chmury. Podstawą jest polityka domyślnego odrzucania dla każdej przestrzeni nazw, z jawnymi regułami zezwalającymi:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: ["Ingress", "Egress"]Nieszyfrowane Secrets i ujawnione metadane
Kubernetes Secrets są kodowane w base64, a nie szyfrowane. Bez szyfrowania etcd w spoczynku są one czytelne dla każdego, kto ma dostęp do etcd lub kopii zapasowej. Co więcej, pody, które mogą dotrzeć do usługi metadanych instancji chmury (169.254.169.254), często mogą ukraść poświadczenia roli IAM węzła—co stanowi pomost od kompromitacji klastra do kompromitacji konta chmurowego.
RBAC: Kto co może zrobić
Kubernetes RBAC kontroluje dostęp do zasobów klastra poprzez Roles, ClusterRoles, RoleBindings i ClusterRoleBindings. Dobre testowanie wykracza poza sprawdzenie, "czy coś jest powiązane z cluster-admin", i poszukuje ścieżek eskalacji—łańcuchów indywidualnie rozsądnie wyglądających uprawnień, które razem dają pełną kontrolę.
Czasowniki, na które należy zwrócić uwagę, to escalate, bind i impersonate. Podmiot, który może create pody, często może zamontować uprzywilejowane konto usługi i odczytać jego token. Podmiot, który może bind role, może przyznać sobie uprawnienia cluster-admin. Podmiot z uprawnieniem impersonate może działać jako dowolny użytkownik. Inne klasyczne ścieżki obejmują możliwość odczytywania Secrets w całym klastrze, tworzenia lub modyfikowania ValidatingWebhookConfigurations (przechwytywanie każdego żądania API) lub wykonywania `exec` do podów działających z wyższymi uprawnieniami.
Praktyczne testowanie RBAC odpowiada na pytania: czy którekolwiek domyślne konto usługi posiada uprawnienia, których nie potrzebuje? Czy podmiot o zakresie przestrzeni nazw może uzyskać dostęp do zasobów o zakresie klastra? Czy istnieją reguły z symbolami wieloznacznymi (resources: ["*"], verbs: ["*"])? Narzędzia takie jak rbac-tool i kubectl-who-can pomagają je wyliczyć, ale interpretacja, czy dany łańcuch jest faktycznie możliwy do wykorzystania, to obszar, w którym testowanie ofensywne zyskuje na wartości.
Testowanie ucieczek z kontenerów
Najbardziej krytyczną klasą podatności w Kubernetesie jest podatność na ucieczkę z kontenera—wydostanie się z kontenera w celu uzyskania dostępu do węzła hosta, a następnie wykorzystanie tego punktu zaczepienia do ruchu bocznego. To jest sedno problemu bezpieczeństwa Dockera w kontekście podatności na ucieczkę z kontenera i dotyczy to niezależnie od tego, czy środowiskiem uruchomieniowym jest containerd, CRI-O, czy Docker.
Wektory ucieczki dzielą się na dwie kategorie. Pierwsza to oparta na konfiguracji: kontener otrzymał wystarczający dostęp, aby się wydostać. Zapisywalny /var/run/docker.sock umożliwia kontenerowi utworzenie nowego uprzywilejowanego kontenera na hoście. Uprzywilejowany pod może zamontować główny system plików hosta i zapisać klucz SSH lub zadanie cron. hostPID ujawnia procesy hosta do wstrzyknięcia. Są to typowe, wysoce prawdopodobne ucieczki, które bezpośrednio odpowiadają powyższym błędom konfiguracji.
Druga kategoria to oparta na exploitach: CVE jądra i środowiska uruchomieniowego. Historyczne przykłady, takie jak CVE-2019-5736 (nadpisanie /proc/self/exe w runc) oraz różne błędy cgroups i jądra, pozwalają atakującemu uciec nawet z rozsądnie skonfigurowanego kontenera. Testowanie w tym przypadku oznacza znajomość używanych wersji środowiska uruchomieniowego i jądra, porównanie ich ze znanymi CVE umożliwiającymi ucieczkę oraz potwierdzenie, że mechanizmy obrony w głębi (seccomp, AppArmor/SELinux, gVisor lub Kata dla obciążeń wysokiego ryzyka) są faktycznie egzekwowane, a nie ustawione na Unconfined.
Realistyczny łańcuch ataku: błąd SSRF w obciążeniu webowym dociera do punktu końcowego metadanych chmury → kradnie rolę IAM węzła → rola może pobierać dane z rejestru kontenerów, a konto serwisowe poda może listować Secrets → Secret zawiera kubeconfig z uprawnieniami cluster-admin → atakujący planuje uprzywilejowany pod na każdym węźle. Każdy krok jest prozaiczny. Połączone, to koniec gry. Jest to dokładnie ten rodzaj wieloetapowej ścieżki, którą pomijają zautomatyzowane skanery pojedynczych problemów.
Skanowanie bezpieczeństwa kontenerów vs Testowanie środowiska uruchomieniowego vs Testy penetracyjne klastra
Zespoły często pytają, które narzędzie "zapewnia bezpieczeństwo Kubernetes". Szczera odpowiedź jest taka, że istnieją trzy różne dyscypliny, odpowiadają one na różne pytania, a dojrzały program wykorzystuje wszystkie trzy. Zrozumienie skanowania bezpieczeństwa kontenerów vs testowania środowiska uruchomieniowego—i gdzie plasują się testy penetracyjne klastra—jest kluczem do niewydawania budżetu na nakładające się pokrycie, jednocześnie pozostawiając prawdziwe luki.
| Wymiar | Skanowanie obrazów | Testowanie środowiska uruchomieniowego | Penetration Testing klastra |
|---|---|---|---|
| Na jakie pytanie odpowiada | Czy ten obraz zawiera znane, podatne na ataki pakiety? | Czy uruchomione obciążenie zachowuje się bezpiecznie w tej chwili? | Czy atakujący może faktycznie skompromitować klaster? |
| Kiedy jest uruchamiane | Kompilacja / rejestr / brama CI | Ciągle, w działającym klastrze | W danym momencie, w sposób wrogi |
| Co sprawdza | Warstwy obrazu, pakiety OS, biblioteki, Dockerfile | Wywołania systemowe, zachowanie procesów, przepływy sieciowe, dryf | RBAC, ścieżki ucieczki, ruch boczny, exploity obciążeń |
| Wykrywa | CVE, nieaktualne zależności, sekrety w warstwach | Anomalie, koparki kryptowalut, nieoczekiwane wyjścia | Łańcuchowe, możliwe do wykorzystania ścieżki ataku od początku do końca |
| Pomija | Konfiguracja środowiska uruchomieniowego, RBAC, błędy logiczne | Ukryte błędne konfiguracje, które nie zostały jeszcze uruchomione | Problemy poza oknem testowym |
| Przykładowe narzędzia | Trivy, Grype, Clair | Falco, Tetragon, Sysdig | kube-hunter, manualny Penetration Test, Penetrify |
| Dopasowanie do automatyzacji | W pełni automatyzowalne w CI | Zawsze aktywny agent | Zaplanowane + ciągłe, oparte na AI |
Skanowanie obrazów jest tanie, szybkie i powinno być częścią każdego potoku—jednak idealnie zeskanowany obraz nadal działa jako root z zamontowanym hostPath, jeśli na to pozwolisz. Testowanie środowiska uruchomieniowego wykrywa to, co się dzieje, ale niewiele mówi o tym, co mogłoby się wydarzyć. Penetration Testing klastra jest jedynym z tych trzech, który dowodzi możliwości wykorzystania podatności poprzez łączenie wyników w sposób, w jaki zrobiłby to atakujący. Żadne z nich nie zastępuje pozostałych.
Narzędzia: kube-bench, kube-hunter i Trivy
Solidny proces skanowania bezpieczeństwa kontenerów dla Kubernetes zazwyczaj łączy trzy otwarte narzędzia, każde z jasno określoną rolą. Są komplementarne, a nie konkurencyjne.
kube-bench
kube-bench uruchamia CIS Kubernetes Benchmark na Twoich węzłach i płaszczyźnie sterowania. Jest audytorem konfiguracji: sprawdza flagi serwera API, ustawienia kubelet, uprawnienia plików na komponentach klastra oraz konfigurację etcd pod kątem dobrze znanego standardu wzmacniania bezpieczeństwa. Uruchom go na każdym węźle i w CI w odniesieniu do manifestów Twojego klastra. Informuje, czy Twój klaster jest zbudowany zgodnie ze specyfikacją; nie informuje, czy specyfikacja jest atakowana.
kube-hunter
kube-hunter to aktywne narzędzie rozpoznawcze. Skierowane na klaster (lub uruchomione jako pod w jego wnętrzu), bada ono odsłonięte kubelety, dostępne punkty końcowe API, usługę metadanych i znane słabe punkty, a następnie raportuje, co atakujący mógłby odkryć. Jest bliższe skanerowi sieciowemu dla Kubernetes niż pełnemu Penetration Testowi—doskonałe do mapowania powierzchni, ograniczone w dowodzeniu kompleksowego wykorzystania podatności.
Trivy
Trivy to skaner typu szwajcarski scyzoryk: CVE obrazów kontenerów, skanowanie błędnych konfiguracji manifestów IaC i Kubernetes, ujawnione sekrety oraz generowanie SBOM. Jest naturalnym wyborem dla powyższej kolumny skanowania obrazów i czysto integruje się z potokami kompilacji. Połącz go z kube-bench dla pokrycia konfiguracji i kube-hunter dla rozpoznania na żywo, a uzyskasz solidną otwartą bazę.
Czego to trio nie robi, to analizowanie logiki aplikacji, łączenie błędu warstwy webowej w przejęcie klastra, ani dostosowywanie swojego podejścia w sposób, w jaki zrobiłby to ludzki atakujący. To jest luka, którą zajmuje się następna sekcja. Aby włączyć te skanery do swojego potoku dostarczania, zobacz nasz przewodnik po testowaniu penetracyjnym CI/CD i automatyzacji bezpieczeństwa potoku.
Warstwa Web i API Obciążeń
Oto część, którą większość programów bezpieczeństwa Kubernetes niedocenia: same obciążenia. Twój klaster hostuje aplikacje webowe i API, i to właśnie tam zazwyczaj następuje początkowe przejęcie kontroli. Atakujący rzadko zaczyna od skradzionego kubeconfiga—zaczyna od SSRF, obejścia uwierzytelniania lub błędu wstrzyknięcia w usłudze, którą wdrożyłeś, a następnie przechodzi do klastra, wykorzystując powyższe błędne konfiguracje.
To jest dokładnie miejsce, w którym pasuje autonomiczne testowanie penetracyjne AI. Skanery konfiguracji i benchmarki CIS nie są w stanie znaleźć obejścia uwierzytelniania logiki biznesowej w Twojej usłudze płatności; nigdy nie zostały do tego zaprojektowane. Testowanie oparte na AI sprawdza działające punkty końcowe webowe i API w Twoich obciążeniach w sposób, w jaki zrobiłby to atakujący—badając uwierzytelnianie, autoryzację, wstrzyknięcia i SSRF—a następnie podąża za łańcuchem: od błędu obciążenia, do zamontowanego tokenu konta usługi, do uprawnień klastra, które ten token odblokowuje, do roli IAM w chmurze stojącej za węzłem.
To ciągłe, łańcuchowe pokrycie warstwy aplikacji uzupełnia—zamiast zastępować—Twój potok kube-bench i Trivy. Dla wymiaru specyficznego dla API, nasze szczegółowe opracowanie na temat automatyzacji testowania bezpieczeństwa API obejmuje OWASP API Top 10 i wyjaśnia, jak sprawić, by to testowanie było powtarzalne we wszystkich wdrożeniach.
Jeśli nadal planujesz, które obciążenia i klastry priorytetyzować, powiązany post na temat testowania bezpieczeństwa kontenerów dla obrazów Docker i ochrony środowiska uruchomieniowego szczegółowo omawia aspekty obrazów i środowiska uruchomieniowego, a także nasz przewodnik po naprawianiu typowych błędnych konfiguracji klastrów Kubernetes przedstawia konkretne kroki naprawcze dla powyższych problemów.
Testowanie Kubernetes z Penetrify
Penetrify w testowaniu bezpieczeństwa Kubernetes obejmuje RBAC, bezpieczeństwo podów, polityki sieciowe, zarządzanie sekretami, wektory ucieczki z kontenerów oraz zarządzane konfiguracje Kubernetes (EKS, AKS, GKE). Testowanie ocenia zarówno warstwę Kubernetes, jak i warstwę integracji z dostawcą chmury—ponieważ kompromitacja Kubernetes często prowadzi do kompromitacji konta w chmurze poprzez połączone konta usług i role IAM.
Różnica w kosztach jest powodem, dla którego zespoły to automatyzują. Tradycyjny, manualny Penetration Test Kubernetes od firmy konsultingowej zazwyczaj kosztuje od 5 000 do 50 000 USD za zlecenie i dostarcza migawkę stanu w danym momencie, która staje się nieaktualna w chwili wdrożenia kolejnej wersji. Penetrify działa w sposób ciągły, od 100 do 5 000 USD miesięcznie, ponownie testując za każdym razem, gdy Twój klaster się zmienia. Aby uzyskać pełniejsze zestawienie, co wpływa na te liczby, zobacz nasze porównanie kosztów Penetration Testing.
Podsumowanie
Kubernetes dodaje całą warstwę orkiestracji powierzchni ataku na szczycie Twojej infrastruktury chmurowej. Testowanie tego wymaga trzech uzupełniających się dyscyplin—skanowania obrazów, monitorowania środowiska uruchomieniowego i cluster Penetration Testing—plus testowania ofensywnego obciążeń webowych i API, które dają atakującym ich pierwszy punkt zaczepienia. Skanery konfiguracji wzmacniają kompilację; tylko exploit-chaining Penetration Testing dowodzi, co atakujący może faktycznie osiągnąć.
Penetrify łączy autonomiczny AI Penetration Testing Twoich obciążeń z testowaniem integracji klastra i chmury, w sposób ciągły i już od 100 USD/mies.—dzięki czemu bezpieczeństwo Twojego Kubernetes nadąża za każdym wdrożeniem, zamiast za każdym rocznym audytem.