Kubernetes nenahrádza vaše problémy so zabezpečením aplikácií—namiesto toho na ne pridáva vrstvu orchestrácie. Každý klaster zavádza riadiacu rovinu (control plane), runtime uzla (node runtime), identitný model, softvérovo definovanú sieť a úložisko tajomstiev (secrets store), pričom každý z nich má svoje vlastné režimy zlyhania. Jediný príliš benevolentný RoleBinding alebo jeden pod s privileged: true môže zmeniť webovú chybu nízkej závažnosti na úplné prevzatie klastra a odtiaľ na kompromitáciu cloudového účtu, ktorý za ním stojí.
Táto príručka podrobne opisuje, ako skutočne testovať prostredie Kubernetes: útočnú plochu, chybné konfigurácie, ktoré sa objavujú takmer pri každom audite, vektory úniku z kontajnera, ktoré z kompromitovaného podu urobia root na uzle, a ako do seba zapadajú tri disciplíny—skenovanie obrazov (image scanning), testovanie za behu (runtime testing) a Penetration Testing klastra—.
Útočná plocha Kubernetes
Pred testovaním si zmapujte, čo vidí útočník. Klaster Kubernetes odhaľuje štyri vysoko hodnotné komponenty a každý z nich je samostatným cieľom s odlišnými režimami zlyhania.
API server
Kube-apiserver je vstupnou bránou ku všetkému. Každý príkaz kubectl, každý kontrolér, každá záťaž (workload), ktorá komunikuje s klastrom, prechádza cez neho. Testovanie API servera znamená kontrolu, či je anonymný prístup zakázaný, či je vynútená autentifikácia (nielen RBAC autorizácia sediaca za otvorenými dverami), či sú nastavené príznaky --anonymous-auth=false a audit-logging, a či koncový bod nie je zbytočne vystavený verejnému internetu. Prekvapivé množstvo spravovaných a samo-hostovaných klastrov stále ponecháva API server dostupný odkiaľkoľvek len s ochranou založenou na tokenoch.
Kubelet
Každý uzol spúšťa kubelet, ktorý vystavuje API (predvolený port 10250) na správu podov na danom uzle. Ak kubelet umožňuje neautentifikovaný alebo len na čítanie prístup (starší port 10255), útočník, ktorý sa dostane k uzlu—alebo podu, ktorý k nemu môže smerovať—môže vymenovať bežiace pody, prečítať ich prostredie a v chybne nakonfigurovaných klastroch vykonávať príkazy vo vnútri kontajnerov. Kubelet je klasický pivotný bod, ktorý kube-hunter vyhľadáva.
etcd
etcd je databáza klastra. Ukladá každý objekt, vrátane Secrets, v nešifrovanej podobe (plaintext), pokiaľ nie je explicitne povolené šifrovanie v pokoji (encryption at rest). Priamy prístup k etcd je ekvivalentný s oprávneniami cluster-admin: môžete čítať všetky poverenia a prepisovať stav klastra. Testovanie overuje, že etcd je dostupné len z riadiacej roviny (control plane), vyžaduje vzájomné TLS a má nakonfigurovaný --encryption-provider-config, aby Secrets neboli uložené v nešifrovanej podobe.
RBAC a identita
Riadenie prístupu na základe rolí (Role-based access control) je spojivovým tkanivom. Rozhoduje o tom, ktoré subjekty môžu pristupovať ku ktorým zdrojom. Pretože RBAC je aditívne a je ľahké udeliť príliš veľa oprávnení, je to najčastejší zdroj ciest k eskalácii privilégií v reálnych klastroch—podrobne popísané nižšie.
Bežné chybné konfigurácie klastra
Fráza chybná konfigurácia zabezpečenia klastra Kubernetes pokrýva predvídateľnú sadu vzorov. Toto sú zistenia, ktoré sa objavujú takmer pri každom prvom posúdení, zoradené približne podľa toho, ako často vedú k skutočnému kompromitovaniu.
Privilegované pody a pody s nadmernými schopnosťami
Pod s securityContext.privileged: true má efektívne neobmedzený prístup k hostiteľovi. Aj bez plných privilégií, nebezpečné schopnosti ako CAP_SYS_ADMIN, allowPrivilegeEscalation: true alebo spustenie ako UID 0 dávajú útočníkovi oveľa viac, než potrebuje záťaž (workload). Riešením je reštriktívny bezpečnostný kontext aplikovaný všade:
Pripojenia hostPath a zdieľané menné priestory
Zväzok hostPath pripojí adresár z uzla do podu. Pripojte /, /var/run/docker.sock alebo /etc/kubernetes a kontajner môže čítať alebo zapisovať do súborového systému hostiteľa—okamžitý únik. To isté platí pre hostPID, hostNetwork a hostIPC, ktoré narúšajú izolačnú hranicu medzi podom a uzlom. Testovanie označí akúkoľvek záťaž, ktorá ich požaduje, pokiaľ neexistuje zdokumentovaný a auditovaný dôvod (napríklad CNI alebo monitorovací DaemonSet).
Predvolené tokeny servisných účtov
Predvolene každý pod získa token servisného účtu default menného priestoru pripojený na /var/run/secrets/kubernetes.io/serviceaccount/token. Ak má tento servisný účet akékoľvek zmysluplné RBAC oprávnenia—alebo ak záťaž vôbec nepotrebuje prístup k API—token predstavuje voľný materiál pre poverenia pre každého, kto prenikne do podu. Nastavte automountServiceAccountToken: false pre záťaže, ktoré nevolajú API, a obmedzte tie, ktoré volajú.
Chýbajúce NetworkPolicies
Štandardne je sieť Kubernetes plochá: akýkoľvek pod môže dosiahnuť akýkoľvek iný pod v akomkoľvek mennom priestore. Bez NetworkPolicies môže jeden kompromitovaný front-end pod komunikovať priamo s vašou databázou, vašimi internými administrátorskými službami a koncovým bodom metadát cloudu. Základom je politika predvoleného zamietnutia pre každý menný priestor s explicitnými pravidlami povolenia:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: ["Ingress", "Egress"]Nešifrované Secrets a odhalené metadáta
Kubernetes Secrets sú kódované v base64, nie šifrované. Bez šifrovania etcd v pokoji sú čitateľné pre každého, kto má prístup k etcd alebo zálohe. Navyše, pody, ktoré môžu dosiahnuť službu metadát cloudovej inštancie (169.254.169.254), môžu často ukradnúť poverenia IAM roly uzla—čo je mostík od kompromitácie klastra ku kompromitácii cloudového účtu.
RBAC: Kto čo môže robiť
Kubernetes RBAC kontroluje prístup k zdrojom klastra prostredníctvom Roles, ClusterRoles, RoleBindings a ClusterRoleBindings. Dobré testovanie presahuje rámec „je niečo viazané na cluster-admin“ a hľadá cesty eskalácie—reťazce individuálne rozumne vyzerajúcich oprávnení, ktoré sa spájajú do plnej kontroly.
Slovesá, na ktoré si treba dávať pozor, sú escalate, bind a impersonate. Subjekt, ktorý môže create pody, môže často pripojiť privilegovaný servisný účet a prečítať jeho token. Subjekt, ktorý môže bind roly, si môže udeliť cluster-admin. Subjekt s impersonate môže konať ako ktorýkoľvek používateľ. Medzi ďalšie klasické cesty patrí schopnosť čítať Secrets v rámci celého klastra, vytvárať alebo upravovať ValidatingWebhookConfigurations (zachytávanie každej požiadavky API) alebo spúšťať príkazy do podov bežiacich s vyššími oprávneniami.
Praktické RBAC testovanie odpovedá na otázky: má nejaký predvolený servisný účet oprávnenia, ktoré nepotrebuje? Môže subjekt s obmedzeným rozsahom menného priestoru dosiahnuť zdroje s rozsahom klastra? Existujú pravidlá so zástupnými znakmi (resources: ["*"], verbs: ["*"])? Nástroje ako rbac-tool a kubectl-who-can pomáhajú tieto možnosti vymenovať, ale interpretácia toho, či je reťazec skutočne zneužiteľný, je to, kde si útočné testovanie zaslúži svoje miesto.
Testovanie úniku z kontajnera
Najkritickejšou triedou nálezu v Kubernetes je container escape vulnerability—únik z kontajnera za účelom prístupu k hostiteľskému uzlu a následné využitie tohto oporného bodu na laterálny pohyb. Toto je jadrom problému container escape vulnerability docker security a platí bez ohľadu na to, či je vaším runtime prostredím containerd, CRI-O alebo Docker.
Vektory úniku spadajú do dvoch kategórií. Prvá je riadená konfiguráciou: kontajneru bol udelený dostatočný prístup na únik. Zapisovateľný /var/run/docker.sock umožňuje kontajneru vytvoriť nový privilegovaný kontajner na hostiteľovi. Privilegovaný pod môže pripojiť koreňový súborový systém hostiteľa a zapísať SSH kľúč alebo cron úlohu. hostPID odhaľuje hostiteľské procesy pre injekciu. Toto sú bežné úniky s vysokou pravdepodobnosťou a priamo súvisia s vyššie uvedenými chybnými konfiguráciami.
Druhá kategória je riadená exploitmi: CVE zraniteľnosti jadra a runtime prostredia. Historické príklady ako CVE-2019-5736 (prepis /proc/self/exe v runc) a rôzne chyby v cgroups a jadre umožňujú útočníkovi uniknúť aj z primerane nakonfigurovaného kontajnera. Testovanie v tomto prípade znamená poznať verzie runtime prostredia a jadra, ktoré používate, skontrolovať ich voči známym únikovým CVE a potvrdiť, že kontroly obrany do hĺbky (seccomp, AppArmor/SELinux, gVisor alebo Kata pre vysoko rizikové záťaže) sú skutočne vynucované, a nie nastavené na Unconfined.
Realistický reťazec útoku: chyba SSRF vo webovej záťaži dosiahne koncový bod metadát cloudu → ukradne rolu IAM uzla → rola môže sťahovať z registru kontajnerov a servisný účet podu môže vypísať Secrets → Secret obsahuje kubeconfig s oprávneniami cluster-admin → útočník naplánuje privilegovaný pod na každý uzol. Každý krok je bežný. Ak sú zreťazené, je to koniec hry. Presne toto je typ viacstupňovej cesty, ktorú automatizované skenery s jedným problémom prehliadajú.
Skenovanie bezpečnosti kontajnerov vs. Testovanie runtime prostredia vs. Penetration Testing klastra
Tímy sa často pýtajú, ktorý nástroj "zabezpečuje bezpečnosť Kubernetes". Úprimná odpoveď je, že existujú tri rôzne disciplíny, ktoré odpovedajú na rôzne otázky, a zrelý program ich všetky prevádzkuje. Pochopenie rozdielu medzi skenovaním bezpečnosti kontajnerov a testovaním runtime prostredia—a kde sa nachádza Penetration Testing klastra—je kľúčom k tomu, aby ste neplytvali rozpočtom na prekrývajúce sa pokrytie a zároveň nezanechávali skutočné medzery.
| Aspekt | Skenovanie obrazov | Testovanie za behu | Penetration Testing klastra |
|---|---|---|---|
| Otázka, na ktorú odpovedá | Obsahuje tento obraz známe zraniteľné balíky? | Správa sa spustená záťaž v súčasnosti bezpečne? | Môže útočník skutočne kompromitovať klaster? |
| Kedy sa spúšťa | Fáza zostavenia / register / CI brána | Nepretržite, v živom klastri | V danom čase, s útočným prístupom |
| Čo kontroluje | Vrstvy obrazov, OS balíky, knižnice, Dockerfile | Systémové volania, správanie procesov, sieťové toky, drift | RBAC, únikové cesty, laterálny pohyb, exploity záťaže |
| Zachytáva | CVEs, zastarané závislosti, tajomstvá vo vrstvách | Anomálie, kryptominery, neočakávaný odchádzajúci prenos | Zreťazené, zneužiteľné útočné cesty od začiatku do konca |
| Prehliada | Konfigurácia za behu, RBAC, logické chyby | Latentné nesprávne konfigurácie, ktoré ešte neboli spustené | Problémy mimo testovacieho okna |
| Príklady nástrojov | Trivy, Grype, Clair | Falco, Tetragon, Sysdig | kube-hunter, manuálny Penetration Test, Penetrify |
| Vhodnosť pre automatizáciu | Plne automatizovateľné v CI | Vždy aktívny agent | Plánované + nepretržité riadené AI |
Skenovanie obrazov je lacné, rýchle a patrí do každého pipeline—ale dokonale naskenovaný obraz stále beží ako root s pripojením hostPath, ak mu to dovolíte. Testovanie za behu zachytáva, čo sa deje, ale málo vám povie o tom, čo by sa mohlo stať. Penetration Testing klastra je jediný z troch, ktorý preukazuje zneužiteľnosť reťazením zistení spôsobom, akým by to urobil útočník. Žiadny z nich nenahrádza ostatné.
Nástroje: kube-bench, kube-hunter a Trivy
Robustný pracovný postup skenovania bezpečnosti kontajnerov pre Kubernetes zvyčajne kombinuje tri open-source ťahúne, každý s jasnou úlohou. Sú komplementárne, nie konkurenčné.
kube-bench
kube-bench spúšťa CIS Kubernetes Benchmark proti vašim uzlom a riadiacej rovine. Je to audítor konfigurácie: kontroluje príznaky API servera, nastavenia kubeletu, súborové oprávnenia na komponentoch klastra a konfiguráciu etcd oproti známemu štandardu zabezpečenia. Spustite ho na každom uzle a v CI proti vašim manifestom klastra. Povie vám, či je váš klaster postavený podľa špecifikácie; nepovie vám, či je špecifikácia napadnutá.
kube-hunter
kube-hunter je nástroj na aktívny prieskum. Nameraný na klaster (alebo spustený ako pod v ňom), skúma exponované kubelety, prístupné API koncové body, službu metadát a známe slabé miesta, potom hlási, čo by útočník mohol objaviť. Je bližšie k sieťovému skeneru pre Kubernetes než k plnému Penetration Testu—vynikajúci pre mapovanie povrchu, obmedzený pre preukázanie end-to-end zneužitia.
Trivy
Trivy je skener typu „švajčiarsky nôž“: CVEs obrazov kontajnerov, skenovanie nesprávnych konfigurácií IaC a Kubernetes manifestov, exponované tajomstvá a generovanie SBOM. Je prirodzenou voľbou pre stĺpec skenovania obrazov vyššie a čisto sa integruje do build pipeline. Spárujte ho s kube-bench pre pokrytie konfigurácie a kube-hunter pre živý prieskum a získate silný open-source základ.
Čo toto trio nerobí, je uvažovanie o logike vašej aplikácie, reťazenie chyby webovej vrstvy do prevzatia klastra alebo prispôsobovanie svojho prístupu tak, ako by to urobil ľudský útočník. To je medzera, ktorú rieši nasledujúca sekcia. Pre zapojenie týchto skenerov do vášho dodávacieho pipeline si pozrite nášho sprievodcu CI/CD Penetration Testingom a automatizáciou bezpečnosti pipeline.
Vrstva webu a API pre pracovné záťaže
Tu je časť, ktorú väčšina bezpečnostných programov Kubernetes podceňuje: samotné pracovné záťaže. Váš klaster hostí webové aplikácie a API, a práve tam zvyčajne dochádza k počiatočnému prieniku. Útočník zriedka začína ukradnutým kubeconfigom—začína s SSRF, obídením autentifikácie (auth bypass) alebo injekčnou chybou v službe, ktorú ste nasadili, a potom sa presunie do klastra pomocou vyššie uvedených nesprávnych konfigurácií.
Presne tu sa uplatňuje autonómny AI Penetration Testing. Konfiguračné skenery a CIS benchmarky nedokážu nájsť obídenie autentifikácie (auth bypass) obchodnej logiky vo vašej platobnej službe; na to neboli nikdy navrhnuté. Testovanie riadené AI preveruje bežiace webové a API koncové body vo vašich pracovných záťažiach tak, ako by to urobil útočník—testovaním autentifikácie, autorizácie, injekcie a SSRF—a potom sleduje reťazec: od chyby v pracovnej záťaži, k pripojenému tokenu servisného účtu, k oprávneniam klastra, ktoré tento token odomyká, až po cloudovú IAM rolu za uzlom.
Toto nepretržité pokrytie aplikačnej vrstvy reťazením exploitov dopĺňa—namiesto toho, aby nahrádzalo—váš kube-bench a Trivy pipeline. Pre dimenziu špecifickú pre API, náš podrobný pohľad na automatizáciu testovania bezpečnosti API pokrýva OWASP API Top 10 a ako zabezpečiť opakovateľnosť tohto testovania naprieč nasadeniami.
Ak stále mapujete, ktoré pracovné záťaže a klastre uprednostniť, sprievodný príspevok o testovaní bezpečnosti kontajnerov pre Docker obrazy a ochranu počas behu pokrýva hlbšie stránky obrazov a behu, a náš podrobný návod na opravu bežných nesprávnych konfigurácií klastrov Kubernetes poskytuje konkrétne kroky na nápravu vyššie uvedených problémov.
Testovanie Kubernetes s Penetrify
Penetrify testovanie bezpečnosti Kubernetes pokrýva RBAC, bezpečnosť podov, sieťové politiky, správu tajomstiev, vektory úniku z kontajnerov a spravované konfigurácie Kubernetes (EKS, AKS, GKE). Testovanie hodnotí vrstvu Kubernetes aj integračnú vrstvu poskytovateľa cloudu—pretože kompromitácia Kubernetes často vedie ku kompromitácii cloudového účtu prostredníctvom prepojených servisných účtov a IAM rolí.
Rozdiel v nákladoch je dôvod, prečo to tímy automatizujú. Tradičný manuálny Kubernetes Penetration Test od konzultačnej firmy zvyčajne stojí 5 000 až 50 000 dolárov za jedno zapojenie a poskytuje vám časovú snímku, ktorá je zastaraná v momente, keď odošlete ďalšie nasadenie. Penetrify beží nepretržite od 100 do 5 000 dolárov mesačne, pričom opakovane testuje zakaždým, keď sa váš klaster zmení. Pre podrobnejší rozpis toho, čo ovplyvňuje tieto čísla, si pozrite naše porovnanie nákladov na Penetration Testing.
Zhrnutie
Kubernetes pridáva celú orchestráciu ako vrstvu útočnej plochy nad vašou cloudovou infraštruktúrou. Jeho testovanie si vyžaduje tri komplementárne disciplíny—skenovanie obrazov, monitorovanie počas behu a cluster Penetration Testing—plus útočné testovanie webových a API záťaží, ktoré útočníkom poskytujú prvý oporný bod. Skenery konfigurácie posilňujú zostavenie; iba Penetration Testing s reťazením exploitov dokáže, čo útočník skutočne dokáže dosiahnuť.
Penetrify kombinuje autonómny AI Penetration Testing vašich záťaží s testovaním integrácie klastra a cloudu, nepretržite a už od 100 $/mesiac—takže vaša Kubernetes bezpečnosť drží krok s každým nasadením namiesto každoročného auditu.