Kubernetes nenahrazuje vaše problémy se zabezpečením aplikací—pouze na ně přidává orchestrační vrstvu. Každý cluster zavádí řídicí rovinu, runtime uzlu, model identit, softwarově definovanou síť a úložiště tajemství, přičemž každá z těchto součástí má své vlastní režimy selhání. Jediný příliš benevolentní RoleBinding nebo jeden privileged: true pod může proměnit webovou chybu s nízkou závažností v úplné převzetí clusteru a odtud v kompromitaci cloudového účtu, který za ním stojí.
Tato příručka popisuje, jak skutečně testovat prostředí Kubernetes: plochu útoku, chybné konfigurace, které se objevují téměř v každém auditu, vektory úniku z kontejneru, které promění kompromitovaný pod v root na uzlu, a jak se k sobě hodí tři disciplíny—skenování obrazů, testování za běhu a Penetration Testing clusteru.
Plocha útoku Kubernetes
Než začnete testovat, zmapujte, co vidí útočník. Cluster Kubernetes odhaluje čtyři vysoce hodnotné komponenty a každá z nich je samostatným cílem s odlišnými režimy selhání.
API server
Kube-apiserver je přední dveře ke všemu. Každý příkaz kubectl, každý controller, každá pracovní zátěž, která komunikuje s clusterem, prochází jím. Testování API serveru znamená kontrolu, zda je anonymní přístup zakázán, zda je vynucena autentizace (nejen RBAC autorizace sedící za otevřenými dveřmi), zda jsou nastaveny příznaky --anonymous-auth=false a auditního logování a zda koncový bod není zbytečně vystaven veřejnému internetu. Překvapivé množství spravovaných a samoobslužných clusterů stále ponechává API server dosažitelný odkudkoli pouze s ochranou založenou na tokenech.
Kubelet
Každý uzel spouští kubelet, který odhaluje API (výchozí port 10250) pro správu podů na daném uzlu. Pokud kubelet umožňuje neautentizovaný nebo pouze pro čtení přístup (starší port 10255), útočník, který se dostane k uzlu—nebo pod, který k němu může směrovat—může vyjmenovat běžící pody, číst jejich prostředí a v chybně nakonfigurovaných clusterech spouštět příkazy uvnitř kontejnerů. Kubelet je klasický pivotní bod, který kube-hunter hledá.
etcd
etcd je databáze clusteru. Ukládá každý objekt, včetně Secrets, v nešifrované podobě, pokud není explicitně povoleno šifrování v klidu. Přímý přístup k etcd je ekvivalentní cluster-admin: můžete číst každé pověření a přepisovat stav clusteru. Testování ověřuje, že etcd je dosažitelné pouze z řídicí roviny, vyžaduje vzájemné TLS a má nakonfigurováno --encryption-provider-config tak, aby Secrets nebyly uloženy v nešifrované podobě.
RBAC a identity
Řízení přístupu na základě rolí je spojovací tkáň. Rozhoduje, které subjekty mohou přistupovat ke kterým zdrojům. Protože RBAC je aditivní a snadno se s ním uděluje příliš mnoho oprávnění, je to jediný nejčastější zdroj cest k eskalaci oprávnění v reálných clusterech—podrobněji popsáno níže.
Běžné chybné konfigurace clusteru
Fráze chybná konfigurace zabezpečení clusteru Kubernetes pokrývá předvídatelnou sadu vzorů. Jedná se o zjištění, která se objevují téměř v každém prvním posouzení, seřazená zhruba podle toho, jak často vedou ke skutečné kompromitaci.
Privilegované a příliš schopné pody
Pod s securityContext.privileged: true má prakticky neomezený přístup k hostiteli. I bez plných oprávnění, nebezpečné schopnosti jako CAP_SYS_ADMIN, allowPrivilegeEscalation: true nebo běh jako UID 0 dávají útočníkovi mnohem více, než pracovní zátěž potřebuje. Řešením je restriktivní bezpečnostní kontext aplikovaný všude:
Připojení hostPath a sdílené jmenné prostory
Svazek hostPath připojí adresář z uzlu do podu. Připojte /, /var/run/docker.sock nebo /etc/kubernetes a kontejner může číst nebo zapisovat do souborového systému hostitele – okamžitý únik. Totéž platí pro hostPID, hostNetwork a hostIPC, které narušují izolační hranici mezi podem a uzlem. Testování označí jakoukoli pracovní zátěž, která tyto požadavky má, pokud neexistuje zdokumentovaný a auditovaný důvod (například CNI nebo monitorovací DaemonSet).
Výchozí tokeny servisních účtů
Ve výchozím nastavení každý pod získá token servisního účtu default jmenného prostoru připojený na /var/run/secrets/kubernetes.io/serviceaccount/token. Pokud má tento servisní účet jakákoli smysluplná RBAC oprávnění – nebo pokud pracovní zátěž vůbec nepotřebuje přístup k API – je token volným přihlašovacím materiálem pro kohokoli, kdo pod kompromituje. Nastavte automountServiceAccountToken: false u pracovních zátěží, které nevolají API, a omezte rozsah těch, které volají.
Chybějící NetworkPolicies
Standardně je síť Kubernetes plochá: jakýkoli pod může dosáhnout na jakýkoli jiný pod v jakémkoli jmenném prostoru. Bez NetworkPolicies může jeden kompromitovaný front-end pod přímo komunikovat s vaší databází, vašimi interními administrátorskými službami a koncovým bodem metadat cloudu. Základem je politika výchozího zamítnutí pro každý jmenný prostor s explicitními pravidly povolení:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: ["Ingress", "Egress"]Nešifrované Secrets a odhalená metadata
Kubernetes Secrets jsou kódovány base64, nikoli šifrovány. Bez šifrování etcd v klidovém stavu jsou čitelné kýmkoli s přístupem k etcd nebo zálohám. K tomu se přidává, že pody, které mohou dosáhnout na službu metadat cloudové instance (169.254.169.254), mohou často ukrást přihlašovací údaje role IAM uzlu – což je most od kompromitace clusteru ke kompromitaci cloudového účtu.
RBAC: Kdo může co dělat
Kubernetes RBAC řídí přístup k prostředkům clusteru prostřednictvím Roles, ClusterRoles, RoleBindings a ClusterRoleBindings. Dobré testování přesahuje otázku „je něco vázáno na cluster-admin“ a hledá cesty eskalace – řetězce individuálně rozumně vypadajících oprávnění, která se spojují do plné kontroly.
Slova k sledování jsou escalate, bind a impersonate. Subjekt, který může create pody, může často připojit privilegovaný servisní účet a přečíst jeho token. Subjekt, který může bind role, si může udělit cluster-admin. Subjekt s impersonate může jednat jako jakýkoli uživatel. Mezi další klasické cesty patří schopnost číst Secrets v celém clusteru, vytvářet nebo upravovat ValidatingWebhookConfigurations (zachycující každý API požadavek) nebo spouštět příkazy do podů běžících s vyššími oprávněními.
Praktické RBAC testování odpovídá na otázky: má nějaký výchozí servisní účet oprávnění, která nepotřebuje? Může subjekt s rozsahem jmenného prostoru dosáhnout na prostředky s rozsahem clusteru? Existují pravidla se zástupnými znaky (resources: ["*"], verbs: ["*"])? Nástroje jako rbac-tool a kubectl-who-can pomáhají tyto enumerovat, ale interpretace, zda je řetězec skutečně zneužitelný, je to, kde se prosazuje útočné testování.
Testování úniku z kontejneru
Nejkritičtější třídou nálezu v Kubernetes je zranitelnost umožňující únik z kontejneru—únik z kontejneru za účelem přístupu k hostitelskému uzlu a následné využití tohoto opěrného bodu pro laterální pohyb. To je jádrem problému zabezpečení Dockeru proti zranitelnostem umožňujícím únik z kontejneru a platí bez ohledu na to, zda je vaším runtime prostředím containerd, CRI-O, nebo Docker.
Vektory úniku spadají do dvou kategorií. První je řízená konfigurací: kontejneru byl udělen dostatečný přístup k úniku. Zapisovatelný soubor /var/run/docker.sock umožňuje kontejneru vytvořit nový privilegovaný kontejner na hostiteli. Privilegovaný pod může připojit kořenový souborový systém hostitele a zapsat SSH klíč nebo úlohu cronu. hostPID zpřístupňuje hostitelské procesy pro injekci. Jedná se o běžné úniky s vysokou pravděpodobností, které přímo souvisejí s výše uvedenými chybnými konfiguracemi.
Druhou kategorií jsou úniky řízené exploity: kernelové a runtime CVE. Historické příklady jako CVE-2019-5736 (přepsání /proc/self/exe v runc) a různé chyby v cgroups a jádře umožňují útočníkovi uniknout i z rozumně nakonfigurovaného kontejneru. Testování zde znamená znát, jaké verze runtime a jádra používáte, porovnat je se známými CVE pro úniky a potvrdit, že jsou kontroly obrany do hloubky (seccomp, AppArmor/SELinux, gVisor nebo Kata pro vysoce rizikové úlohy) skutečně vynuceny, spíše než nastaveny na Unconfined.
Realistický útočný řetězec (kill chain): chyba SSRF ve webové aplikaci dosáhne koncového bodu cloudových metadat → ukradne IAM roli uzlu → role může stahovat z registru kontejnerů a servisní účet podu může vypisovat Secrets → Secret obsahuje kubeconfig s oprávněními cluster-admin → útočník naplánuje privilegovaný pod na každý uzel. Každý krok je všední. Zřetězeně to znamená konec hry. Přesně tento typ vícestupňové cesty automatizované skenery s jedním problémem přehlížejí.
Skenování zabezpečení kontejnerů vs. testování runtime vs. Penetration Testing clusteru
Týmy se často ptají, který nástroj "zajišťuje zabezpečení Kubernetes". Upřímná odpověď je, že existují tři různé disciplíny, které odpovídají na různé otázky, a zralý program provozuje všechny tři. Pochopení rozdílu mezi skenováním zabezpečení kontejnerů a testováním runtime—a kde se nachází Penetration Testing clusteru—je klíčem k tomu, abyste neplýtvali rozpočtem na překrývající se pokrytí a zároveň nezanechávali skutečné mezery.
| Dimenze | Skenování obrazů | Testování za běhu | Penetration Testing clusteru |
|---|---|---|---|
| Na jakou otázku odpovídá | Obsahuje tento obraz známé zranitelné balíčky? | Chová se spuštěná úloha v tuto chvíli bezpečně? | Může útočník skutečně kompromitovat cluster? |
| Kdy se spouští | Build / registry / CI brána | Nepřetržitě, v živém clusteru | V daném okamžiku, útočně |
| Co kontroluje | Vrstvy obrazů, balíčky OS, knihovny, Dockerfile | Systémová volání, chování procesů, síťové toky, drift | RBAC, únikové cesty, laterální pohyb, exploity úloh |
| Odhaluje | CVEs, zastaralé závislosti, tajemství ve vrstvách | Anomálie, krypto-minery, neočekávaný odchozí provoz | Zřetězené, zneužitelné útočné cesty od začátku do konce |
| Přehlíží | Konfigurace za běhu, RBAC, logické chyby | Latentní chybné konfigurace, které ještě nebyly spuštěny | Problémy mimo testovací okno |
| Příklady nástrojů | Trivy, Grype, Clair | Falco, Tetragon, Sysdig | kube-hunter, manuální Penetration Test, Penetrify |
| Vhodnost pro automatizaci | Plně automatizovatelné v CI | Stále aktivní agent | Plánované + nepřetržité řízené umělou inteligencí |
Skenování obrazů je levné, rychlé a patří do každé pipeline—ale perfektně naskenovaný obraz stále běží jako root s připojením hostPath, pokud mu to dovolíte. Testování za běhu zachytí, co se děje, ale málo vám řekne o tom, co by se mohlo stát. Penetration Testing clusteru je jediný ze tří, který prokazuje zneužitelnost řetězením zjištění způsobem, jakým by to udělal útočník. Žádný nenahrazuje ostatní.
Nástroje: kube-bench, kube-hunter a Trivy
Robustní workflow pro skenování bezpečnosti kontejnerů pro Kubernetes obvykle kombinuje tři open-source tahouny, každý s jasnou rolí. Jsou komplementární, nikoli konkurenční.
kube-bench
kube-bench spouští CIS Kubernetes Benchmark proti vašim uzlům a řídicí rovině. Je to auditor konfigurace: kontroluje příznaky API serveru, nastavení kubeletu, oprávnění souborů na komponentách clusteru a konfiguraci etcd proti známému standardu pro posílení bezpečnosti. Spusťte jej na každém uzlu a v CI proti vašim manifestům clusteru. Řekne vám, zda je váš cluster postaven podle specifikace; neřekne vám, zda je specifikace napadána.
kube-hunter
kube-hunter je nástroj pro aktivní průzkum. Zaměřený na cluster (nebo spuštěný jako pod uvnitř něj), prohledává exponované kubelety, dostupné API koncové body, službu metadat a známá slabá místa, a poté hlásí, co by útočník mohl objevit. Je blíže síťovému skeneru pro Kubernetes než plnohodnotnému Penetration Testu—vynikající pro mapování povrchu, omezený pro prokázání end-to-end zneužití.
Trivy
Trivy je skener jako švýcarský armádní nůž: CVEs obrazů kontejnerů, skenování chybných konfigurací IaC a Kubernetes manifestů, odhalená tajemství a generování SBOM. Je přirozenou volbou pro sloupec skenování obrazů výše a čistě se integruje do build pipelines. Spárujte jej s kube-bench pro pokrytí konfigurace a kube-hunter pro živý průzkum, a získáte silný open-source základ.
Co toto trio nedělá, je uvažování o aplikační logice, řetězení chyby webové vrstvy do převzetí klastru, nebo přizpůsobení svého přístupu tak, jak by to udělal lidský útočník. To je mezera, kterou řeší následující sekce. Pro zapojení těchto skenerů do vaší dodávací pipeline se podívejte na našeho průvodce CI/CD Penetration Testingem a automatizací zabezpečení pipeline.
Vrstva webových aplikací a API pro pracovní zátěže
Zde je část, kterou většina bezpečnostních programů Kubernetes podceňuje: samotné pracovní zátěže. Váš klastr hostuje webové aplikace a API, a právě odtud obvykle pochází počáteční průnik. Útočník zřídka začíná s ukradeným kubeconfigem—začíná s SSRF, obcházením autentizace, nebo chybou injekce ve službě, kterou jste nasadili, a poté se přesune do klastru pomocí výše uvedených chybných konfigurací.
Přesně zde se uplatňuje autonomní AI Penetration Testing. Konfigurační skenery a CIS benchmarky nemohou najít obcházení autentizace založené na obchodní logice ve vaší platební službě; k tomu nebyly nikdy navrženy. Testování řízené umělou inteligencí prověřuje běžící webové a API koncové body uvnitř vašich pracovních zátěží způsobem, jakým by to udělal útočník—zkoumá autentizaci, autorizaci, injekci a SSRF—a poté sleduje řetězec: od chyby v pracovní zátěži, k připojenému tokenu servisního účtu, k oprávněním klastru, která tento token odemyká, až po cloudovou IAM roli za uzlem.
Toto nepřetržité pokrytí aplikační vrstvy s řetězením exploitů doplňuje—spíše než nahrazuje—vaši kube-bench a Trivy pipeline. Pro dimenzi specifickou pro API, náš podrobný průzkum automatizace testování zabezpečení API pokrývá OWASP API Top 10 a jak zajistit opakovatelnost tohoto testování napříč nasazeními.
Pokud stále plánujete, které pracovní zátěže a klastry prioritizovat, doprovodný příspěvek o testování zabezpečení kontejnerů pro Docker obrazy a ochranu za běhu pokrývá hlouběji aspekty obrazů a běhového prostředí, a náš průvodce opravou běžných chybných konfigurací klastrů Kubernetes poskytuje konkrétní kroky k nápravě výše uvedených problémů.
Testování Kubernetes s Penetrify
Penetrify testování zabezpečení Kubernetes pokrývá RBAC, zabezpečení podů, síťové politiky, správu tajemství, vektory úniku z kontejnerů a spravované konfigurace Kubernetes (EKS, AKS, GKE). Testování vyhodnocuje jak vrstvu Kubernetes, tak integrační vrstvu poskytovatele cloudu—protože kompromitace Kubernetes často vede ke kompromitaci cloudového účtu prostřednictvím propojených servisních účtů a IAM rolí.
Rozdíl v nákladech je důvodem, proč týmy automatizují. Tradiční manuální Kubernetes Penetration Test od konzultační firmy obvykle stojí 5 000 až 50 000 $ za zakázku a poskytuje vám snímek v čase, který je zastaralý v okamžiku, kdy nasadíte další verzi. Penetrify běží nepřetržitě od 100 do 5 000 $ měsíčně a znovu testuje pokaždé, když se váš klastr změní. Pro podrobnější rozpis toho, co ovlivňuje tato čísla, se podívejte na naše srovnání nákladů na Penetration Testing.
Závěr
Kubernetes přidává celou orchestraci jako vrstvu útočné plochy nad vaší cloudovou infrastrukturou. Jeho testování vyžaduje tři doplňkové disciplíny—skenování obrazů, monitorování za běhu a Penetration Testing clusteru—plus útočné testování webových a API úloh, které útočníkům poskytují první opěrný bod. Konfigurační skenery zpevňují sestavení; pouze Penetration Testing řetězení exploitů prokazuje, čeho může útočník skutečně dosáhnout.
Penetrify kombinuje autonomní AI Penetration Testing vašich úloh s testováním integrace clusteru a cloudu, nepřetržitě a od 100 $/měsíc—takže vaše zabezpečení Kubernetes drží krok s každým nasazením namísto každoročního auditu.