Zabezpečení Kubernetes clusterů pomocí cloudového Penetration Testing

Pravděpodobně jste už slyšeli frázi: „Kubernetes je operační systém cloudu.“ Pro mnohé z nás v DevOps a bezpečnosti je to v podstatě pravda. Je výkonný, škáluje se jako sen a zvládá orchestraci kontejnerů způsobem, který umožňuje, aby se nasazování složitých aplikací zdálo zvládnutelné. Ale je tu jedna věc: Kubernetes je také neuvěřitelně složitý. Když máte systém s tolika pohyblivými částmi – pody, nody, služby, ingressy a masivní API server – plocha pro chybu je obrovská.

Většina týmů začíná s výchozí konfigurací nebo se řídí rychlým průvodcem. To funguje pro zprovoznění aplikace, ale zřídka to funguje pro udržení zlých hochů venku. Jediné chybně nakonfigurované pravidlo Role-Based Access Control (RBAC) nebo kontejner spuštěný jako root může dát útočníkovi přímou cestu z veřejně přístupného webového serveru k tajemstvím celého vašeho clusteru. Je to noční můra, ale stává se to častěji, než si lidé chtějí připustit.

Zde přichází na řadu cloudový Penetration Testing. Nemůžete jen spustit standardní síťový skener a říct, že je hotovo. Moderní clustery potřebují specifický druh kontroly – takový, který chápe, jak kontejnery mezi sebou komunikují a jak lze oklamat orchestraci. Simulací reálných útoků v kontrolovaném prostředí najdete díry dříve, než to udělá někdo jiný.

V této příručce se ponoříme hluboko do toho, jak zabezpečit vaše Kubernetes clustery. Podíváme se na specifické zranitelnosti, které trápí prostředí K8s, a proč je cloud-nativní přístup k Penetration Testing jedinou cestou, jak si udržet náskok.

Pochopení útočné plochy Kubernetes

Než budeme mluvit o tom, jak testovat, musíme pochopit, co vlastně testujeme. Kubernetes není jen jeden kus softwaru; je to ekosystém. Pokud s ním zacházíte jako s tradičním VM, uniká vám většina rizik.

Řídicí rovina: Mozek operace

Řídicí rovina je nejcitlivější část vašeho clusteru. Pokud útočník získá přístup k API serveru, je po všem. Může vytvářet pody, krást tajemství a vypnout celou vaši infrastrukturu. Mezi běžná rizika zde patří:

Neověřený přístup k API: Někdy je API server omylem vystaven veřejnému internetu bez řádného ověření.
Nezabezpečené konfigurace Kubelet: Pokud Kubelet (agent na každém nodu) není zabezpečen, může útočník spouštět příkazy přímo na nodu.
Zranitelnosti Etcd: Etcd je místo, kde K8s ukládá všechna svá data. Pokud databáze etcd není šifrovaná nebo omezená, tajemství vašeho clusteru v podstatě sedí v nešifrované podobě.

Datová rovina: Kde se děje práce

Zde žijí vaše pody a kontejnery. Zatímco řídicí rovina je mozek, datová rovina je sval – a zde dochází k většině počátečních průniků.

Komunikace Pod-to-Pod: Ve výchozím nastavení K8s umožňuje, aby každý pod komunikoval s jakýmkoli jiným podem. Pokud je frontendový pod kompromitován, může se útočník přesunout stranou k backendovému databázovému podu bez jakéhokoli odporu.
Privilegované kontejnery: Některé kontejnery jsou spuštěny jako „privilegované“, což znamená, že mají téměř stejný přístup jako hostitelský stroj. Pokud je tento kontejner prolomen, může útočník „uniknout“ z kontejneru a převzít kontrolu nad skutečným nodem.
Nezabezpečené registry obrazů: Pokud stahujete obrazy z veřejného registru bez jejich ověření, můžete nasazovat kontejner, který již má nainstalovaná zadní vrátka.

Síťová vrstva: Neviditelná dálnice

Síťování Kubernetes je bestie. Mezi CNI (Container Network Interface), Ingress controllery a Service meshe existuje spousta míst, kde se může něco pokazit. Chybně nakonfigurovaný Ingress může vystavit interní služby světu a nedostatek Network Policies znamená, že váš „interní“ provoz je široce otevřený.

Proč tradiční skenování zabezpečení nestačí

Pokud máte skener zranitelností, který kontroluje zastaralé verze softwaru, děláte holé minimum. To je v pořádku pro shodu, ale není to zabezpečení. Zde je důvod, proč tradiční skenování selhává ve světě Kubernetes.

Statické vs. dynamické riziko

Statické skenování vám řekne, že váš obraz má známé CVE (Common Vulnerabilities and Exposures). To je užitečné, ale neříká vám to, zda je tato zranitelnost skutečně dosažitelná. Například knihovna může mít chybu, ale pokud vaše aplikace nikdy tuto knihovnu nevolá, riziko je nulové. Naopak, váš software může být 100% aktuální, ale vaše RBAC oprávnění mohou umožnit jakémukoli uživateli smazat celý namespace. Statický skener to nikdy nenajde.

Složitost provozu „East-West“

Většina tradičních firewallů se zaměřuje na provoz „North-South“ – co přichází z internetu a co odchází. Ale v K8s je skutečné nebezpečí provoz „East-West“ – komunikace mezi pody. Tradiční skenery obvykle sedí mimo cluster. Nemohou vidět, co se děje uvnitř sítě podů. Cloudový Penetration Testing však simuluje útočníka, který již získal oporu, což vám umožní přesně vidět, jak daleko se může posunout.

Efemérnost a drift

Kontejnery mají být krátkodobé. Spustí se, udělají svou práci a zemřou. To vytváří problém „driftu“. Můžete naskenovat svůj obraz v CI/CD pipeline a zjistit, že je čistý. Ale jakmile běží v clusteru, exploit za běhu může změnit stav tohoto kontejneru. Pokud neprovádíte aktivní cloudové testování, spoléháte se na snímek zabezpečení ze tří týdnů zpět.

Hloubkový ponor: Běžné zranitelnosti Kubernetes a jak je testovat

Chcete-li skutečně zabezpečit cluster, musíte přemýšlet jako útočník. Zde jsou nejběžnější způsoby, jak jsou clustery prolomeny, a jak by je identifikoval Penetration Tester (nebo platforma jako Penetrify).

1. RBAC s nadměrnými oprávněními

Role-Based Access Control (RBAC) je srdcem zabezpečení K8s. Problém je, že je těžké ho správně nastavit. Mnoho týmů dává roli cluster-admin servisním účtům jen proto, aby to "fungovalo".

Útočný scénář: Útočník najde zranitelnost ve webové aplikaci běžící v podu. Zjistí, že servisní účet podu má oprávnění list secrets v celém clusteru. Použije to ke krádeži API tokenu pro privilegovanější účet, čímž efektivně eskaluje svá oprávnění na cluster admin.

Jak testovat:

Auditujte všechny ClusterRoleBindings.
Hledejte jakýkoli servisní účet s * (wildcard) oprávněními.
Použijte nástroje jako kubectl auth can-i ke kontrole, co konkrétní pod skutečně může dělat.
Zkuste se přesunout z podu s nízkými oprávněními na API server a zjistit, zda můžete stahovat secrets z jiných namespaců.

2. Úniky z kontejneru (Escape to Host)

Celý smysl kontejneru je izolace. Pokud je ale kontejner nesprávně nakonfigurován, je tato izolace lež.

Útočný scénář: Kontejner je spuštěn s hostPath mounty, což znamená, že vidí souborový systém hostitele. Útočník získá přístup k podu a uvědomí si, že vidí /etc/shadow na skutečném fyzickém uzlu. Ukradne root heslo uzlu a nyní ovládá hardware.

Jak testovat:

Zkontrolujte, zda pody neběží jako privileged: true.
Hledejte hostPath mounty, zejména ty, které směřují do citlivých adresářů, jako je /etc nebo /var/run/docker.sock.
Pokuste se spustit proces v kontejneru, který má přístup k síťovým rozhraním hostitele nebo seznamu procesů.

3. Nebezpečný přístup k API Serveru

API server je "mozek". Pokud je odhalen, cluster je snadný cíl.

Útočný scénář: Vývojář otevře port API serveru (6443) do světa, aby usnadnil ladění z domova. Zapomene ho vypnout. Útočník najde otevřený port, zkusí běžná výchozí hesla nebo objeví neověřený endpoint a začne manipulovat s clusterem.

Jak testovat:

Proveďte port scan na veřejných IP adresách clusteru.
Otestujte neověřený přístup k endpointům /api nebo /healthz.
Ověřte, zda je TLS správně implementováno a zda certifikáty nejsou expirované nebo podepsané samy sebou způsobem, který umožňuje útoky man-in-the-middle.

4. Nedostatečná segmentace sítě

Ve výchozím nastavení je K8s "plochá" síť. Pod A může komunikovat s Podem B, C a Z.

Útočný scénář: Veřejně přístupný frontend pod je kompromitován. Útočník použije nástroj jako nmap uvnitř podu ke skenování zbytku interní sítě. Najde nechráněnou Redis cache obsahující session tokeny a databázi bez hesla, protože "přijímá pouze interní provoz".

Jak testovat:

Nasaďte "útočný pod" v jednom namespacu.
Zkuste curl nebo ping pody v jiných namespacích.
Zkontrolujte, zda jsou NetworkPolicies skutečně vynucovány, nebo zda jsou pouze "doporučeny" v nějakém dokumentu.

Podrobný rámec pro Kubernetes Penetration Testing

Pokud máte za úkol zabezpečit svůj cluster, nezačínejte jen klikat na tlačítka. Potřebujete metodiku. Zde je strukturovaný přístup k cloudovému Penetration Testingu pro Kubernetes.

Fáze 1: Průzkum a sběr informací

Než zaútočíte, musíte vědět, s čím máte co do činění.

Identifikujte distribuci: Je to EKS, GKE, AKS nebo self-managed cluster? Každý má jiné výchozí nastavení zabezpečení.
Zmapujte povrch: Vypište všechny veřejně přístupné Ingress body, LoadBalancery a adresu API serveru.
Analyzujte obrazy: Pokud máte přístup do registru, naskenujte obrazy na známé zranitelnosti.

Fáze 2: Počáteční přístup

Jak se špatný herec dostane dovnitř?

Exploity aplikací: Hledejte SQL Injection nebo Remote Code Execution (RCE) v aplikacích běžících v clusteru.
Uniklé přihlašovací údaje: Prohledejte GitHub, GitLab nebo interní wiki na uniklé soubory kubeconfig nebo servisní účty tokeny.
Útoky na dodavatelský řetězec: Zkontrolujte, zda nějaké použité Helm charty nebo obrazy třetích stran nejsou nedůvěryhodné.

Fáze 3: Post-Exploitation and Lateral Movement

Jakmile jste uvnitř podu, cílem je se pohybovat.

Krádež tokenu servisního účtu: Hledejte v /var/run/secrets/kubernetes.io/serviceaccount/token. Toto je "zlatý lístek" pro pohyb v rámci clusteru.
Interní skenování: Použijte netcat nebo curl k nalezení dalších služeb běžících v interním rozsahu IP adres clusteru.
DNS Enumeration: Použijte interní CoreDNS k nalezení jmen dalších služeb v clusteru.

Fáze 4: Eskalace oprávnění

Nyní se posuňte od "Jsem pod" k "Jsem admin".

RBAC Enumeration: Použijte ukradený token k zjištění, jaká máte oprávnění. Můžete vytvářet pody? Můžete vypisovat secrets?
Node Escape: Pokud jste v privilegovaném kontejneru, zkuste získat přístup k souborovému systému hostitele.
Token Impersonation: Zkontrolujte, zda můžete použít kubectl k impersonaci jiných uživatelů.

Fáze 5: Exfiltrace dat a dopad

Posledním krokem je prokázání rizika.

Krádež Secret: Můžete stáhnout heslo k databázi nebo API klíče z K8s Secret?
Manipulace s prostředky: Můžete nasadit crypto-miner pod, aniž byste byli detekováni?
Denial of Service: Můžete shodit API server nebo smazat kritické namespacy?

Implementace modelu Continuous Security

Jednorázové Penetration Testing jsou skvělé, ale představují jen momentku v čase. Ve světě, kde nasazujete kód tucetkrát denně, je test z minulého měsíce v podstatě k ničemu. Potřebujete způsob, jak zajistit trvalé zabezpečení.

Integrace testování do CI/CD

Cílem je posunout zabezpečení "vlevo". To znamená najít chyby ještě předtím, než se kód dostane do produkčního clusteru.

Infrastructure as Code (IaC) Scanning: Používejte nástroje ke skenování vašich souborů Terraform nebo YAML na přítomnost chybných konfigurací (jako jsou privilegované kontejnery) před jejich aplikací.
Image Signing: Používejte nástroje jako Cosign, abyste zajistili, že budou nasazeny pouze obrazy podepsané vaším build pipeline.
Admission Controllers: Implementujte Policy Engine (jako OPA Gatekeeper nebo Kyverno), který automaticky odmítne jakýkoli pod, který nesplňuje bezpečnostní standardy (např. "Žádné pody spuštěné jako root").

Role automatizovaného cloudového Penetration Testing

Zde se rovnováha mění. Není reálné spouštět plný manuální Penetration Test pokaždé, když odešlete commit. Ale také se nemůžete spoléhat pouze na statické skenery.

Přesně proto jsme vytvořili Penetrify. Namísto volby mezi "pomalými manuálními testy" a "povrchními automatizovanými skeny" poskytuje Penetrify cloud-nativní platformu, která automatizuje složité části Penetration Testing. Dokáže simulovat laterální pohyb a eskalaci privilegií, o kterých jsme mluvili, ale dělá to způsobem, který se škáluje s vaší infrastrukturou.

Používáním cloudové platformy nemusíte trávit týdny nastavováním infrastruktury pro testování vašeho clusteru. Můžete spouštět hodnocení na vyžádání, přesně vidět, jak by se útočník pohyboval vašimi pody, a získat jasný plán nápravy, který vašim vývojářům přesně řekne, co mají opravit.

Porovnání bezpečnostních přístupů: Scanner vs. Pentest vs. Penetrify

Může být matoucí vědět, který nástroj kdy použít. Zde je jednoduchý rozpis.

Funkce	Vulnerability Scanner	Manuální Pentest	Penetrify
Rychlost	Rychlá / Okamžitá	Pomalá / Týdny	Rychlá / Na vyžádání
Hloubka	Povrchová úroveň (CVE)	Hluboká (Složité řetězce)	Vysoká (Automatizované řetězce)
Cena	Nízká / Předplatné	Vysoká / Za projekt	Střední / Škálovatelná
Frekvence	Kontinuální	Roční / Čtvrtletní	Průběžná / Na vyžádání
Kontext	Nízký (Nezná logiku K8s)	Vysoký (Lidská intuice)	Vysoký (Logika s ohledem na K8s)
Náprava	Obecné "Aktualizujte verzi"	Podrobná zpráva	Akční pokyny

Běžné chyby při zabezpečení Kubernetes

I zkušení týmy dělají tyto chyby. Pokud je vidíte ve svém prostředí, měli byste upřednostnit jejich okamžitou opravu.

Chyba 1: Důvěra interní síti

Mnoho lidí si myslí: "Jakmile je provoz uvnitř clusteru, je to bezpečné." To je největší chyba, kterou můžete udělat. Jakmile útočník pronikne do jednoho podu, má "důvěryhodnou" pozici. Pokud nemáte zavedeny NetworkPolicies, v podstatě jste útočníkovi dali klíč od každé místnosti v domě.

Chyba 2: Nadměrné spoléhání se na Namespaces pro zabezpečení

Namespaces jsou skvělé pro organizaci, ale nejsou bezpečnostní hranicí. Ve výchozím nastavení mohou pody v namespace-a komunikovat s pody v namespace-b. Pokud používáte namespaces k izolaci "Prod" od "Dev" na stejném clusteru, hrajete nebezpečnou hru. Používejte oddělené clustery nebo velmi přísné NetworkPolicies.

Chyba 3: Ignorování Kubelet a Etcd

Všichni se soustředí na API server, ale Kubelet (na uzlu) a Etcd (databáze) jsou často ponechány zcela otevřené. Pokud se útočník dostane na uzel, může komunikovat s Kubelet lokálně a často zcela obejít omezení API serveru.

Chyba 4: Spouštění jako Root

Je překvapivě běžné vidět kontejnery spuštěné jako uživatel root. Pokud je v aplikaci zranitelnost, útočník má okamžitě root oprávnění uvnitř kontejneru, což výrazně usnadňuje host breakout. Vždy zadejte runAsUser ve svém SecurityContext.

Kontrolní seznam nápravy: Zabezpečení vašeho clusteru

Našli jste spoustu děr během posledního testu? Zde je praktický kontrolní seznam, jak dostat váš cluster zpět do bezpečného stavu.

Okamžitá vítězství (Nízké úsilí, vysoký dopad)

Zakázat Root: Nastavte runAsNonRoot: true ve vašich pod security contexts.
Omezit přístup k API: Umístěte API server za VPN nebo použijte IP allow-listing.
Povolit Network Policies: Zaveďte zásadu "deny all" a explicitně povolte pouze provoz, který je skutečně potřeba.
Vyčistit RBAC: Odstraňte všechny role cluster-admin ze servisních účtů, které je ve skutečnosti nepotřebují.

Střednědobé zabezpečení

Implementujte Policy Engine: Nainstalujte Kyverno nebo OPA pro automatické vynucování bezpečnostních pravidel.
Rotujte hesla: Nastavte systém pro pravidelnou rotaci K8s hesel a API tokenů.
Ověření obrazů: Implementujte proces podepisování, aby bylo možné spouštět pouze ověřené obrazy.
Zabezpečení uzlů: Použijte OS optimalizovaný pro kontejnery (jako Talos nebo Bottlerocket) ke snížení prostoru pro útok na uzel.

Dlouhodobá strategie

Zero Trust Architecture: Posuňte se směrem k service mesh (jako Istio nebo Linkerd) pro vzájemné TLS (mTLS) mezi všemi pody.
Průběžné hodnocení: Integrujte platformu jako Penetrify do svého měsíčního nebo čtvrtletního bezpečnostního cyklu.
Chaos Security Engineering: Začněte záměrně narušovat bezpečnostní kontroly v testovacím prostředí, abyste zjistili, zda se vaše upozornění skutečně aktivují.

Scénář z reálného světa: Průlom "Hop-by-Hop"

Abychom ilustrovali, proč je cloudový Penetration Testing tak důležitý, podívejme se na hypotetický (ale velmi častý) scénář průlomu.

Nastavení: Společnost provozuje maloobchodní aplikaci na EKS clusteru. Mají frontend (React), backend API (Node.js) a databázi (MongoDB). Pro frontend používají standardní LoadBalancer.

Cesta průlomu:

Vstup: Útočník najde zastaralý NPM balíček v Node.js backendu, který umožňuje útok Server-Side Request Forgery (SSRF).
První skok: Pomocí SSRF útočník dotazuje interní K8s metadata službu a najde token servisního účtu pro backend pod.
Eskalace: Útočník zjistí, že servisní účet backend podu má oprávnění get secrets pro celý namespace. Vytáhnou heslo MongoDB.
Pivot: Útočník použije heslo k přihlášení do databáze. Jakmile jsou uvnitř, najdou v databázové verzi exploit, který jim umožňuje spouštět kód na základním uzlu.
Převzetí kontroly: Z uzlu útočník přistupuje k Kubelet API a začne nasazovat škodlivé pody po celém clusteru, aby těžil kryptoměny a kradl zákaznická data.

Jak by Pentest toto zastavil: Cloudový Penetration Test by označil zranitelnost SSRF v backendu. I kdyby byl SSRF zmeškán, test by identifikoval, že servisní účet má nadměrná oprávnění get secrets. Dále nedostatek NetworkPolicy umožnil backend podu komunikovat s databází bez omezení. Nalezením těchto "článků v řetězu" vám Penetrify pomáhá přerušit řetěz dříve, než útočník dokončí cestu.

FAQ: Cloudový Penetration Testing pro Kubernetes

Otázka: Zpomaluje Penetration Testing výkon mého clusteru? Obecně ne. Profesionální cloudový Penetration Testing je navržen tak, aby nenarušoval provoz. Zatímco některé náročné skeny mohou způsobit menší špičky, většina testů se zaměřuje na chyby konfigurace a logiky spíše než na "zátěžové testování" hardwaru. Vždy však doporučujeme testovat v testovacím prostředí, které zrcadlí produkční prostředí.

Otázka: Jak často bych měl provádět posouzení zabezpečení Kubernetes? Pokud nasazujete denně, měli byste mít automatizované skenování denně. Ale Penetration Test v plné hloubce by měl probíhat alespoň čtvrtletně, nebo kdykoli provedete významnou změnu ve své architektuře (jako je přechod na nový CNI nebo změna struktury RBAC).

Otázka: Nemohu jen použít "Security Group" v AWS/Azure/GCP k zabezpečení mého clusteru? Security Groups řeší pouze "perimetr" – provoz North-South. Nemohou vidět, co se děje uvnitř vašeho clusteru. Pokud je pod kompromitován, Security Group nezabrání tomu, aby tento pod útočil na jiné pody ve stejném clusteru. Potřebujete interní kontroly, jako jsou NetworkPolicies a RBAC.

Otázka: Jaký je rozdíl mezi skenováním zranitelností a Penetration Testem? Skenování je jako kontrola, zda jsou zamčené vchodové dveře. Penetration Test je jako pokusit se vypáčit zámek, prolézt oknem a zjistit, zda najdete šperkovnici v ložnici. Jeden najde chyby; druhý dokazuje, jak lze tyto chyby použít k způsobení skutečné škody.

Otázka: Potřebuji specializovaný bezpečnostní tým, abych mohl používat platformu jako Penetrify? Ne nutně. I když odborné znalosti pomáhají, Penetrify je navržen tak, aby překlenul mezeru. Poskytuje hloubku profesionálního pentestera, ale poskytuje výsledky způsobem, kterému mohou DevOps inženýři a IT manažeři porozumět a jednat na základě nich, aniž by potřebovali doktorát z kybernetické bezpečnosti.

Dáváme to všechno dohromady

Zabezpečení Kubernetes není úkol "jednou a hotovo". Je to nepřetržitý proces utahování šroubů a kontroly prasklin. Složitost cloudu znamená, že chyby jsou nevyhnutelné. Cílem není mít "dokonalý" cluster – protože ten neexistuje – ale mít odolný cluster.

Odolný cluster je ten, kde je API uzamčeno, kde pody mají minimální oprávnění, která potřebují k fungování, a kde je síť segmentována tak, aby jeden průlom nevedl k úplnému kolapsu.

Nejnebezpečnější věc, kterou můžete udělat, je předpokládat, že jste zabezpečeni, protože jste se řídili průvodcem nastavením. Jediný způsob, jak si být jistý, je pokusit se sami vloupat – nebo ještě lépe, použít nástroj navržený tak, aby to udělal za vás.

Pokud vás už nebaví hádat, zda je váš cluster skutečně zabezpečený, je čas posunout se za základní skenování. Ať už máte malý tým nebo masivní podnikovou infrastrukturu, potřebujete způsob, jak simulovat skutečné útoky bez zbytečné zátěže masivního poradenského projektu.

Jste připraveni najít mezery ve svém zabezpečení Kubernetes dříve, než to udělají ti špatní?

Podívejte se na Penetrify. Poskytujeme cloudové možnosti Penetration Testing, které potřebujete k identifikaci, posouzení a nápravě zranitelností v reálném čase. Přestaňte doufat, že jsou vaše konfigurace správné, a začněte si být jisti, že tomu tak je. Zabezpečte svou infrastrukturu, chraňte svá data a spěte klidněji s vědomím, že váš cluster je skutečně odolný.

Zpět na blog