Jeden pod z internetu.
Klucze do całego klastra.
Klaster Kubernetes w produkcji: dziesiątki zasobów, mikroserwisy, CI/CD, dane klientów. Domyślne ustawienia wyglądały „normalnie" — bo Kubernetes domyślnie jest wygodny, nie bezpieczny. Pokazujemy, jak audyt wg CIS Benchmark i wytycznych NSA/CISA zamienia listę „failed controls" w realną ścieżkę: od jednego kontenera do przejęcia węzła i sekretów całego klastra.
kont serwisowych
do hosta
w całym klastrze
na węzeł
Kubernetes nie jest niebezpieczny. Jest domyślnie wygodny — a to jest dużo gorsze, bo wygoda wygląda jak działający system, podczas gdy bezpieczeństwo trzeba świadomie dołożyć. Większość firm wdraża klaster, „bo działa", i nigdy nie wraca do ustawień, które domyślnie są pootwierane.
Domyślny klaster pozwala kontenerom rozmawiać ze sobą bez ograniczeń, nadaje kontom serwisowym szersze uprawnienia, niż potrzeba, i z radością uruchomi poda z dostępem do systemu plików węzła, jeśli ktoś o to poprosi w manifeście. Każda z tych rzeczy z osobna wygląda niewinnie. Razem tworzą prostą drogę od jednego przejętego kontenera do kontroli nad całym klastrem.
Engagement był w pełni autoryzowany. Połączyliśmy automatyczny przegląd konfiguracji (CIS Kubernetes Benchmark przez kube-bench, postura i RBAC przez kubescape z profilami NSA/CISA i MITRE ATT&CK) z manualnym pentestem, który zamienia surowe „failed controls" w realny scenariusz ataku. Wszystko poniżej jest zanonimizowane.
Najpierw mierzymy, co jest pootwierane
Audyt zaczynamy od twardych danych, nie od przeczuć. Dwa narzędzia, dwie perspektywy: kube-bench sprawdza klaster względem CIS Kubernetes Benchmark (konfiguracja API servera, kubeleta, etcd, polityk), a kubescape mapuje posturę na frameworki NSA/CISA Hardening Guide oraz MITRE ATT&CK for Containers, ze szczególnym naciskiem na RBAC i workloady.
Raport z samego skanera to lista setek „failed controls" bez priorytetów — łatwo w niej utonąć i nic nie naprawić. Wartość audytu polega na tym, że łączymy te kontrolki w łańcuchy: które trzy „średnie" znaleziska razem tworzą jedną krytyczną ścieżkę ataku. To jest różnica między raportem do szuflady a planem działania.
Wejście przez aplikację, którą i tak masz w klastrze
Pierwszy kontener rzadko zdobywa się „hakując Kubernetesa". Zdobywa się go przez aplikację, która w tym klastrze działa — podatność w usłudze webowej, wystawiony panel, niezałatana zależność. W momencie, gdy mamy wykonanie kodu wewnątrz jednego poda, zaczyna się prawdziwy audyt: co ten pod widzi i co może zrobić dalej.
Domyślnie Kubernetes montuje token konta serwisowego do każdego poda. Jeśli to konto ma szersze uprawnienia, niż aplikacja realnie potrzebuje (a w domyślnych wdrożeniach prawie zawsze ma), napastnik wewnątrz kontenera dostaje gotowe poświadczenia do rozmowy z API klastra. To jest pierwszy mnożnik zasięgu.
Trzy „średnie" ustawienia = jedna ucieczka na węzeł
Tu materializuje się sens audytu. Pojedyncze znaleziska ze skanera (kontener uprzywilejowany, brak polityk sieciowych, nadmiarowy RBAC) raportowane są często jako „medium". Ale złożone w łańcuch prowadzą do ucieczki z kontenera na węzeł — a węzeł to już nie jedna aplikacja, to wszystkie pody, które na nim działają, wraz z ich sekretami.
Kontrola nad węzłem oznacza dostęp do wszystkiego, co na nim działa: cudzych podów, ich zmiennych środowiskowych, zamontowanych sekretów i tokenów. Stąd, przez wykradzione poświadczenia uprzywilejowanych kont serwisowych, prowadzi już krótka droga do płaszczyzny sterowania — czyli do kontroli nad całym klastrem.
Różnicę dokłada się świadomie — albo wcale.
Co naprawdę leży w Secrets
Finałem nie jest „mam roota w kontenerze". Finałem jest to, co dzięki temu można przeczytać. Obiekty Secret w Kubernetes są domyślnie kodowane Base64 — co wiele osób myli z szyfrowaniem. To nie jest szyfrowanie. Każdy, kto może je odczytać przez API lub z węzła, ma je w postaci jawnej.
To moment, w którym incydent w jednym klastrze przestaje być „problemem DevOps" i staje się ryzykiem dla całej organizacji — bo sekrety z klastra otwierają drzwi do baz danych, chmury i systemów, które z Kubernetesem pozornie nie mają nic wspólnego.
Od skanu do scenariusza ataku
Skan postury
kube-bench (CIS) + kubescape (NSA/CISA, MITRE). Zbieramy twarde dane o konfiguracji, RBAC i workloadach.
Triage znalezisk
Setki „failed controls" porządkujemy w łańcuchy. Szukamy kombinacji, które razem tworzą realną ścieżkę.
Przyczółek w podzie
Wejście przez aplikację działającą w klastrze. Rozpoznanie z wnętrza kontenera: token konta serwisowego, zasięg RBAC.
Eskalacja pod → node
Łańcuch: kontener uprzywilejowany + brak polityk sieciowych + nadmiarowy RBAC. Ucieczka na węzeł.
Sekrety i wpływ
Odczyt Secrets, tokenów i danych. Mapowanie realnego wpływu biznesowego poza sam klaster.
Raport + hardening
Priorytetyzowane znaleziska, dowody (PoC) i konkretny plan utwardzenia. Retest po wdrożeniu poprawek.
Co najczęściej znajdujemy w klastrach Kubernetes
Te kategorie powtarzają się w niemal każdym audycie — od małych klastrów po środowiska produkcyjne dużych firm. To jednocześnie nasza lista kontrolna i najszybsza mapa do utwardzenia Twojego klastra.
| Kategoria | Typowe znalezisko | Severity |
|---|---|---|
| Kontenery uprzywilejowane | privileged, hostPath, hostNetwork, hostPID — droga na węzeł | Critical |
| Nadmiarowy RBAC | Konta serwisowe i role z uprawnieniami znacznie szerszymi niż potrzeba | High |
| Sekrety bez izolacji | Secrets jako Base64, brak szyfrowania at-rest, brak ograniczeń dostępu | High |
| Brak NetworkPolicy | Nieograniczony ruch east-west — każdy pod gada z każdym | High |
| Brak Pod Security Standards | Brak admission control wymuszającego bezpieczne ustawienia podów | Medium |
| Niezałatane komponenty | Stare wersje Kubernetes, kubelet, runtime kontenerów | Medium |
| Słaby audyt i logowanie | Brak audit logów API servera, brak detekcji nietypowych zapytań | Low |
Cztery rzeczy do utwardzenia w pierwszej kolejności
1. Ogranicz RBAC do absolutnego minimum. Każde konto serwisowe powinno mieć dokładnie tyle uprawnień, ile potrzebuje aplikacja — i ani jednego więcej. Wyłącz automatyczne montowanie tokenów tam, gdzie nie są używane.
2. Zablokuj kontenery uprzywilejowane. Wymuszaj Pod Security Standards przez admission control. Żaden pod produkcyjny nie powinien mieć dostępu do hosta bez bardzo dobrego, udokumentowanego powodu.
3. Wprowadź NetworkPolicy. Domyślny brak izolacji sieciowej to autostrada dla ruchu bocznego. Polityka „default deny" plus jawne wyjątki zatrzymuje napastnika w pojedynczym podzie.
4. Traktuj Secrets jak sekrety. Włącz szyfrowanie at-rest, ogranicz kto może je odczytać i rozważ zewnętrzny menedżer sekretów. Base64 to nie zabezpieczenie.
Twój klaster Kubernetes działa. Ale czy jest bezpieczny?
Robimy pełne audyty bezpieczeństwa Kubernetes — przegląd konfiguracji wg CIS Benchmark i wytycznych NSA/CISA (kube-bench, kubescape) połączony z manualnym pentestem, który pokazuje realne ścieżki ataku, nie tylko listę kontrolek. Raport z priorytetami, dowodami i planem hardeningu, plus retest po poprawkach. Zakres i wycena w 2 dni robocze.
Zamów audyt Kubernetes →