Kubernetes sa v podstate stal operačným systémom cloudu. Ak prevádzkujete kontajnery vo veľkom rozsahu, takmer určite používate K8s. Je výkonný, flexibilný a zvláda orchestráciu ako sen. Ale je tu jedna vec: tá istá sila prichádza s obrovským množstvom zložitosti. Keď prejdete z tradičného nastavenia založeného na VM na vrstvu orchestrácie kontajnerov, vaša útočná plocha sa nielen posunie – rozšíri sa smermi, na ktoré sa možno ani nepozeráte.
Väčšina tímov začína svoju cestu s Kubernetes sledovaním niekoľkých základných tutoriálov, spustením klastra na EKS, GKE alebo AKS a nasadením svojich aplikácií. Všetko funguje. Potom pridajú nejaké namespaces, niekoľko ingress controllers a možno nejaké základné Role-Based Access Control (RBAC). Pôsobí to bezpečne. Ale "funguje to" a "je to bezpečné" sú dve veľmi odlišné veci vo svete cloud-native infraštruktúry. Jeden nesprávne nakonfigurovaný YAML súbor alebo prehnane privilegovaný ServiceAccount môže byť rozdiel medzi bezpečným produkčným prostredím a úplným prevzatím klastra.
Tu vstupuje do hry cloud Penetration Testing. Nemôžete len spustiť štandardný sieťový skener proti Kubernetes klastru a povedať, že je to hotové. K8s má svoju vlastnú internú sieť, svoj vlastný API server a svoju vlastnú sadu zvláštností správy identít. Ak chcete skutočne zabezpečiť klaster, musíte premýšľať ako útočník. Musíte sa opýtať: "Ak kompromitujem jeden pod, môžem sa dostať k API serveru? Môžem ukradnúť token zo systému súborov? Môžem sa laterálne presunúť do iného namespace?"
V tejto príručke sa ponoríme hlboko do reality zabezpečenia Kubernetes. Prejdeme od všeobecnej rady "používajte silné heslá" a pozrieme sa na skutočné útočné vektory, ktoré držia bezpečnostných inžinierov hore celú noc. A čo je najdôležitejšie, preskúmame, ako cloud-native prístup k Penetration Testing – ako to, čo sme vytvorili v Penetrify – vám umožní nájsť tieto diery skôr, ako to urobí niekto iný.
Pochopenie útočnej plochy Kubernetes
Predtým, ako budeme hovoriť o tom, ako testovať klaster, musíme pochopiť, čo vlastne testujeme. Kubernetes nie je jedna jediná vec; je to zbierka komponentov, ktoré musia navzájom komunikovať. Ak je ktorýkoľvek z týchto komunikačných kanálov otvorený alebo nesprávne overený, celý domček z kariet sa môže zrútiť.
Riadiaca rovina: Mozog klastra
Riadiaca rovina je primárny cieľ pre každého seriózneho útočníka. Prečo? Pretože ak ovládate API server, ovládate všetko. kube-apiserver je brána pre všetky administratívne úlohy. Ak je vystavený verejnému internetu bez prísnej autentifikácie, alebo ak je v bežiacej verzii zraniteľnosť, útočník môže v podstate vydávať príkazy vášmu klastru, ako keby bol administrátor.
Potom máte etcd. Toto je databáza klastra. Ukladá všetko – tajomstvá, konfiguračné mapy a stav každého podu. Ak útočník získa prístup k etcd, nemusí ani komunikovať s API serverom; môže si prečítať vaše tajomstvá priamo z disku.
Pracovné uzly a Kubelet
Pracovné uzly sú miesta, kde beží váš skutočný kód. kubelet je agent bežiaci na každom uzle, ktorý komunikuje späť s riadiacou rovinou. Bežnou chybou je ponechanie Kubelet API otvoreného alebo povolenie neautentifikovaného prístupu. Ak môžem komunikovať s Kubeletom, môžem byť schopný vykonávať príkazy vo vnútri podu alebo dokonca získať citlivé informácie o prostredí uzla.
Pody a kontajnery
Toto je najbežnejší vstupný bod. Väčšina útokov začína zraniteľnosťou v kóde aplikácie – možno RCE v štýle Log4j alebo jednoduchou SQL Injection. Keď je útočník vo vnútri kontajnera, začne "pod escaping". Hľadá spôsoby, ako sa dostať z kontajnera a na hostiteľský uzol. Odtiaľ hľadá token ServiceAccount, ktorý je zvyčajne pripojený na /var/run/secrets/kubernetes.io/serviceaccount/token.
Sieťová vrstva (CNI)
Sieť Kubernetes je často predvolene "plochá" sieť. To znamená, že predvolene môže každý pod v klastri komunikovať s akýmkoľvek iným podom, bez ohľadu na namespace. Ak je váš frontend webový server kompromitovaný, môže potenciálne odosielať požiadavky do vášho interného API na spracovanie platieb alebo do vašej databázy bez akéhokoľvek firewallu medzi nimi.
Bežné nesprávne konfigurácie Kubernetes, ktoré vedú k narušeniam
Keď robíme Penetration Testing v Penetrify, zriedka nájdeme "Zero Day" zraniteľnosti v základnom kóde Kubernetes. Namiesto toho nájdeme "Zero Day" chyby v spôsobe, akým bol klaster nakonfigurovaný. Toto sú nízko visiace ovocie, ktoré útočníci milujú.
Prehnane privilegované RBAC roly
Role-Based Access Control (RBAC) je najviac nepochopená časť zabezpečenia K8s. Je veľmi ľahké byť frustrovaný chybami "Permission Denied" počas nasadzovania a jednoducho dať ServiceAccount rolu cluster-admin.
Predstavte si jednoduchý monitorovací pod, ktorý potrebuje iba vypísať pody, aby skontroloval ich stav. Ak má tento pod udelené povolenia cluster-admin a aplikácia v ňom je kompromitovaná, útočník má teraz plnú kontrolu nad celým klastrom. Môže mazať namespaces, kradnúť tajomstvá a nasadzovať svoje vlastné škodlivé pody (ako sú ťažiari kryptomien).
Pasca "Privileged" kontajnera
Spustenie kontajnera ako privileged: true v podstate hovorí Kubernetes, aby deaktivoval väčšinu bezpečnostných hraníc medzi kontajnerom a hostiteľom. Privilegovaný kontajner má takmer rovnaký prístup k jadru hostiteľa ako proces bežiaci priamo na uzle. Pre pentestera je privilegovaný kontajner zlatá vstupenka. Uľahčuje únik na hostiteľa, čo im umožňuje prístup k Docker socketu alebo Kubelet API.
Vystavený Dashboard a API Server
Kubernetes Dashboard je skvelý na prehľad, ale ak nie je zabezpečený, je to nočná mora. Videli sme klastre, kde bol dashboard vystavený na internet s predvoleným servisným účtom, ktorý mal administratívne privilégiá. Je to v podstate webové GUI na zničenie vašej vlastnej infraštruktúry. Podobne, ponechanie API servera otvoreného pre 0.0.0.0/0 bez MFA alebo striktného IP whitelistingu je recept na katastrofu.
Nechránené Secrets
Mnohé tímy ukladajú "secrets" v objektoch Kubernetes Secrets. Aj keď to znie správne, pamätajte, že predvolene sú K8s secrets iba kódované v base64, nie šifrované. Ktokoľvek s prístupom k API alebo databáze etcd ich môže dešifrovať v priebehu niekoľkých sekúnd. Ak nepoužívate dedikovaný KMS (Key Management Service) alebo nástroj ako HashiCorp Vault, vaše secrets v skutočnosti nie sú tajné.
Pracovný postup Cloud Penetration Testing pre Kubernetes
Tradičný Penetration Testing je často "bodový" event: konzultant príde na dva týždne, napíše správu a odíde. Ale prostredia Kubernetes sa menia zakaždým, keď spustíte kubectl apply. Potrebujete kontinuálnejší, cloud-natívny prístup k testovaniu.
Fáza 1: Prieskum a externé mapovanie
Prvým krokom v cloudovom Penetration Teste je zistiť, čo vidí svet. Začíname skenovaním exponovaných endpointov.
- Je API server dosiahnuteľný?
- Je otvorený port Kubelet (10250)?
- Existujú nejaké exponované dashboardy alebo stránky s metrikami Prometheus?
- Ktoré pravidlá ingress umožňujú prenos do klastra?
Fáza 2: Počiatočný prístup ("Footprint")
Keď nájdeme vstupný bod – povedzme zraniteľnú webovú aplikáciu – vytvoríme si oporný bod. To zvyčajne zahŕňa získanie reverzného shellu. Ale akonáhle sme vnútri, cieľ sa mení z "útoku na aplikáciu" na "útok na klaster".
Prvá vec, ktorú pentester urobí, je kontrola tokenu ServiceAccount:
cat /var/run/secrets/kubernetes.io/serviceaccount/token
Ak tento token existuje, môžeme ho použiť na autentifikáciu na API serveri zvnútra podu.
Fáza 3: Interná enumerácia a eskalácia privilégií
Teraz sa pýtame: "Čo môžem s týmto tokenom vlastne robiť?" Používame nástroje ako kubectl auth can-i --list, aby sme videli naše povolenia.
Ak máme povolenia na create pods, môžeme spustiť "škodlivý" pod, ktorý pripojí koreňový súborový systém hostiteľa. Ak máme povolenia na get secrets, môžeme vypísať každé heslo a API kľúč v namespace. Tu sa odohráva "šachová partia" zabezpečenia Kubernetes – presun z podu s nízkymi privilégiami na uzol s vysokými privilégiami.
Fáza 4: Bočný pohyb
Ak klaster nemá Network Policies (verzia firewallu pre K8s), môžeme sa pohybovať laterálne. Skenujeme internú sieť podov, aby sme našli ďalšie služby. Môžeme nájsť neautentifikovanú Redis cache alebo internú databázu, ktorá dôveruje akémukoľvek pripojeniu prichádzajúcemu zvnútra klastra.
Fáza 5: Exfiltrácia a perzistencia
Záverečnou fázou je zistenie, či môžeme ukradnúť dáta alebo udržať prístup. Môžeme vytvoriť "zadné vrátka" Deployment, ktorý sa reštartuje, ak je odstránený? Môžeme ukradnúť IAM metadáta poskytovateľa cloudu z uzla (napr. prístupom k 169.254.169.254 na AWS), aby sme sa presunuli z klastra Kubernetes do širšieho účtu AWS?
Praktické kroky na posilnenie vášho klastra
Ak ste dočítali až sem a myslíte si: "Môj klaster môže byť zraniteľný," nepanikárte. Zabezpečenie je proces neustáleho zlepšovania. Tu je praktický kontrolný zoznam na presun vášho klastra zo "štandardného" na "posilnený".
1. Implementujte striktné Network Policies
Prestaňte predpokladať, že interná sieť je bezpečná. Predvolene implementujte politiku "deny-all" pre ingress aj egress prenos v rámci vašich namespaces. Potom explicitne povoľte iba tie pripojenia, ktoré sú nevyhnutné.
- Pod A by mal komunikovať iba s Podom B na porte 8080.
- Pod B by mal komunikovať iba s databázou na porte 5432.
- Zablokujte všetkým podom komunikáciu s cloudovým metadátovým API, pokiaľ to absolútne nepotrebujú.
2. Vyčistite svoje RBAC
Auditujte svoje roly. Prestaňte používať cluster-admin na všetko.
- Používajte Namespaced Roles namiesto ClusterRoles, kedykoľvek je to možné.
- Dodržiavajte princíp najmenšieho privilégiá (PoLP). Ak pod potrebuje iba čítať ConfigMap, nedávajte mu možnosť ho aktualizovať.
- Pravidelne auditujte, kto má prístup ku klastru, pomocou nástrojov ako
rbac-lookup.
3. Používajte Pod Security Admissions (PSA)
Prestaňte povoľovať privilegované kontajnery. Kubernetes má vstavané Pod Security Admissions, ktoré vám umožňujú presadzovať rôzne úrovne zabezpečenia:
- Privileged: Neobmedzené (v podstate "robte, čo chcete"). Vyhnite sa tomu v produkcii.
- Baseline: Zabraňuje známym eskaláciám privilégií.
- Restricted: Presadzuje veľmi vysoký bezpečnostný štandard (žiadni root používatelia, žiadny prístup k hostiteľskej sieti).
Zamierte na profil restricted pre všetky vaše aplikačné workloady.
4. Zabezpečte svoje Secrets
Prejdite od K8s secrets kódovaných v base64.
- Povoľte Encryption at Rest pre vašu databázu
etcd. - Používajte cloud-natívny secret manager. Napríklad použite AWS Secrets Manager alebo Azure Key Vault a integrujte ich s vašimi podmi pomocou Secret Store CSI Driver. To zaisťuje, že secrets sú vložené do podu za behu a nikdy nie sú uložené ako čistý text v K8s API.
5. Udržujte svoje komponenty aktualizované
Znie to jednoducho, ale tu dochádza k mnohým narušeniam. Zraniteľnosti v kube-apiserver alebo kubelet sú rýchlo opravené, ale ak používate verziu spred dvoch rokov, ste ľahký cieľ. Automatizujte upgrady klastra, aby ste mali aktuálne informácie o najnovších bezpečnostných záplatách.
Porovnanie: Manuálny Penetration Testing vs. Automatizované skenovanie vs. Cloud-Native platformy
Mnohí sa pýtajú: "Nemôžem jednoducho spustiť skener zraniteľností?" Odpoveď je áno, ale skener nie je Penetration Test. Tu je rozdiel.
| Funkcia | Automatizovaný skener zraniteľností | Tradičný manuálny Penetration Test | Cloud-natívna platforma (Penetrify) |
|---|---|---|---|
| Rozsah | Nájde známe CVE v balíkoch. | Hĺbková analýza logiky a konfigurácie. | Kombinuje skenovanie CVE s analýzou konfigurácie. |
| Kontext | Nerozumie RBAC alebo toku siete. | Rozumie kontextu, ale je pomalý. | Mapuje priestor útoku v reálnom čase. |
| Frekvencia | Môže bežať denne. | Raz alebo dvakrát ročne. | Kontinuálne a na požiadanie. |
| Akcieschopnosť | Poskytuje dlhý zoznam "potenciálnych" chýb. | Poskytuje podrobnú správu. | Poskytuje cesty nápravy a integruje sa so SIEM. |
| Cena | Nízka až stredná. | Vysoká (poplatky pre konzultantov). | Škálovateľné predplatné. |
skenery sú skvelé na nájdenie verzie Nginx, ktorá má chybu. Ale skener vám nepovie, že vaša politika RBAC umožňuje podu vývojára vymazať vašu produkčnú databázu. Manuálny pentester to nájde, ale sú drahí a nemôžu byť všade naraz.
Platforma ako Penetrify prekonáva túto medzeru. Používa cloud-natívnu architektúru na automatickú a konzistentnú simuláciu týchto útokov, čím vám poskytuje hĺbku Penetration Testu s rýchlosťou skenera.
Pokročilý scenár: Únik "Pod-to-Cloud"
Aby ste skutočne pochopili, prečo je cloudový pentesting odlišný, pozrime sa na realistický scenár útoku. Toto je bežná cesta, ktorú nachádzame počas hodnotení.
Krok 1: Vstup Útočník nájde zraniteľnosť Server-Side Request Forgery (SSRF) vo verejne prístupnej aplikácii Django bežiacej v pode Kubernetes.
Krok 2: Získanie metadát
Útočník použije SSRF na zasiahnutie koncového bodu metadát poskytovateľa cloudu: http://169.254.169.254/latest/meta-data/iam/security-credentials/. Pretože rola IAM uzla má nadmerné privilégiá, útočník získa dočasný prístupový kľúč AWS.
Krok 3: Skenovanie účtu
Pomocou týchto kľúčov si útočník uvedomí, že má povolenia S3:ListBucket a S3:GetObject pre celý účet AWS. Nájde bucket obsahujúci zálohy produkčnej databázy.
Krok 4: Prevzatie kontroly nad klastrom
Počas prehľadávania S3 bucketu nájde zálohu súboru kubeconfig, ktorý bol omylom nahraný. Tento súbor obsahuje certifikát pre používateľa cluster-admin.
Krok 5: Úplná kontrola
Útočník použije kubeconfig na pripojenie k API serveru zo svojho vlastného notebooku. Teraz má absolútnu moc nad klastrom. Nasadí šifrovaný tunel (ako Ngrok) vo vnútri klastra, aby si udržal trvalé zadné vrátka, obchádzajúc všetky perimetrové firewally.
Ponaučenie? Zraniteľnosť nebola len v aplikácii Django. Bola to reťaz: SSRF $\rightarrow$ Nadmerne privilegované Node IAM $\rightarrow$ Uniknutý tajný kľúč v S3 $\rightarrow$ Admin Kubeconfig. Jednoduchý skener podov by našiel iba zraniteľnosť Django; neukázal by vám, že celý váš účet AWS je ohrozený.
Integrácia zabezpečenia do CI/CD Pipeline (DevSecOps)
Nemôžete len tak "robiť" bezpečnosť na konci. V čase, keď pentester nájde dieru vo vašom produkčnom klastri, škoda (alebo náklady na jej opravu) sú už vysoké. Musíte presunúť bezpečnosť "doľava".
Shift-Left Testing
Integrujte bezpečnostné kontroly do svojich GitLab alebo GitHub pipelines.
- Statická analýza (SAST): Skenujte svoje Dockerfiles na "USER root" a svoje YAML súbory na
privileged: true. - Skenovanie obrazov: Používajte nástroje na zabezpečenie toho, aby vaše základné obrazy nemali známe CVE predtým, ako sa vôbec dostanú do registra.
- Policy as Code: Používajte OPA (Open Policy Agent) alebo Kyverno. Tieto nástroje fungujú ako admission controllers. Ak sa vývojár pokúsi nasadiť pod, ktorý nemá limity zdrojov alebo beží ako root, klaster jednoducho odmietne nasadenie.
Slučka spätnej väzby
Skutočné kúzlo sa stane, keď prepojíte výsledky Penetration Testingu späť do svojho vývojového cyklu. Keď platforma ako Penetrify identifikuje nesprávnu konfiguráciu vo vašom vývojovom klastri, tento poznatok by mal automaticky vytvoriť ticket v Jire pre tím, aby ho opravil.
Bezpečnosť by nemala byť "brána", ktorá zastaví nasadenie; mala by to byť "zvodidlo", ktoré riadi nasadenie. Keď vývojári presne vedia, prečo je určitá konfigurácia nebezpečná (pretože Penetration Test simuloval útok a dokázal to), je oveľa pravdepodobnejšie, že budú od začiatku písať bezpečný kód.
Bežné chyby pri zabezpečovaní Kubernetes
Dokonca aj skúsené tímy na tom stroskotajú. Ak spravujete klaster, skontrolujte, či nerobíte niektorú z týchto vecí.
Chyba 1: Dôverovanie označeniu "Cloud Managed"
Mnoho ľudí predpokladá, že pretože používajú EKS alebo GKE, Google alebo Amazon sa starajú o bezpečnosť. Zatiaľ čo poskytovateľ cloudu zabezpečuje control plane (hlavné uzly), ste stále zodpovední za data plane (vaše pracovné uzly, vaše pody a vaše sieťové politiky). "Shared Responsibility Model" je skutočný. Ak necháte svoj API server otvorený, AWS nezabráni útočníkovi vstúpiť.
Chyba 2: Ignorovanie "Default" Namespace
Namespace default je často miestom, kde končia testy a náhodné pody. Mnohé tímy zabúdajú aplikovať rovnako prísne RBAC a sieťové politiky na namespace default ako na production. Útočník, ktorý sa dostane do "testovacieho" podu v namespace default, ho často môže použiť ako východiskový bod na útok na iné časti klastra.
Chyba 3: Nadmerné spoliehanie sa na skenovanie obrazov
Skenovanie obrazu na CVE je dôležité, ale nestačí to. Obraz môže mať nulový počet známych zraniteľností, ale stále môže byť nakonfigurovaný tak, aby bežal ako root s plným prístupom k PID namespace hostiteľa. Musíte zabezpečiť konfiguráciu runtime, nielen binárku.
Chyba 4: Zlyhanie pri protokolovaní a monitorovaní
Nemôžete zastaviť útok, ktorý nevidíte. Mnohé tímy zabúdajú povoliť Kubernetes Audit Logs. Audit logy vám povedia, kto, čo, kedy a ako urobil. Bez nich, ak útočník ukradne token a vytvorí backdoor, nebudete mať žiadny záznam o tom, ako sa to stalo.
FAQ: Zabezpečenie Kubernetes pomocou cloudového Penetration Testing
Otázka: Ako často by som mal vykonávať Penetration Test na svojom Kubernetes klastri? Odpoveď: Závisí to od frekvencie zmien. Ak posielate kód denne, raz ročne vykonaný Penetration Test je zbytočný. Mali by ste mať automatizované skenovanie denne a hĺbkové Penetration Testing každého štvrťroka alebo po každej väčšej architektonickej zmene. Cloud-natívne platformy umožňujú "continuous pentesting," čo je zlatý štandard.
Otázka: Potrebujem inštalovať agentov na moje uzly pre cloudový Penetration Testing? Odpoveď: Nie nevyhnutne. Mnohé moderné platformy, vrátane Penetrify, používajú kombináciu skenovania založeného na API a kontrolovaných "útočníckych podov" na simuláciu hrozieb bez toho, aby bolo potrebné inštalovať invazívne agenty na každý jeden uzol. To znižuje výkonnostnú réžiu a bezpečnostné riziko samotného testovacieho nástroja.
Otázka: Môže Penetration Testing poškodiť môj produkčný klaster? Odpoveď: Vždy existuje riziko pri akomkoľvek aktívnom testovaní. Preto odporúčame testovanie v staging prostredí, ktoré zrkadlí produkčné prostredie. Avšak, profesionálne cloudové Penetration Testing nástroje sú navrhnuté tak, aby boli nedeštruktívne. Hľadajú "proof of concept" prístup (ako čítanie súboru) namiesto vykonávania "denial of service" útokov.
Otázka: Aký je rozdiel medzi skenovaním zraniteľností a Penetration Testom? Odpoveď: Skenovanie je ako domáci bezpečnostný systém, ktorý kontroluje, či sú dvere zamknuté. Penetration Test je ako najať si niekoho, aby sa skutočne pokúsil vlámať do vášho domu. Skener vám povie, že dvere môžu byť otvorené; pentester skutočne prejde cez dvere a povie vám, že sa môže dostať k vašej šperkovnici v spálni.
Otázka: Stačí RBAC na zabezpečenie klastra? Odpoveď: Nie. RBAC je len jedna vrstva. Potrebujete tiež Network Policies (na zastavenie laterálneho pohybu), Pod Security Admissions (na zastavenie únikov) a Secret Management (na ochranu citlivých údajov). Berte to ako "defense in depth."
Záverečné poznatky a ďalšie kroky
Zabezpečenie Kubernetes nie je o zaškrtnutí jedného políčka; je to o znížení "blast radius." Musíte predpokladať, že v určitom bode bude pod kompromitovaný. Cieľom je zabezpečiť, aby sa útočník v takom prípade ocitol v zamknutej miestnosti bez kľúčov a bez možnosti komunikovať so zvyškom domu.
Ak sa cítite preťažení, začnite s týmito tromi okamžitými krokmi:
- Auditujte svoje RBAC: Nájdite každý ServiceAccount s
cluster-admina zistite, či ho skutočne potrebuje. (Nápoveda: Pravdepodobne nie). - Povoľte Network Policies: Začnite blokovaním všetkej odchádzajúcej prevádzky z vašich podov do cloudového metadata API (
169.254.169.254). - Spustite skutočný test: Prestaňte hádať, či ste zabezpečení. Použite nástroj alebo službu na skutočnú simuláciu útoku.
Komplexnosť Kubernetes je jeho najväčšou silou, ale aj jeho najväčšou slabosťou. Jediný spôsob, ako skutočne poznať svoju pozíciu, je otestovať ju v reálnych podmienkach.
Ak chcete prestať hádať a začať vedieť, Penetrify vám môže pomôcť. Poskytujeme cloud-natívnu infraštruktúru na spustenie bezpečnostných posúdení na profesionálnej úrovni bez masívnej réžie tradičného poradenstva. Pomôžeme vám nájsť medzery vo vašom RBAC, diery vo vašich sieťových politikách a cesty k eskalácii privilégií skôr, ako to urobí škodlivý aktér.
Nečakajte na narušenie, aby ste zistili, že váš "zabezpečený" klaster mal dokorán otvorené dvere. Navštívte Penetrify.cloud ešte dnes a získajte jasný, použiteľný prehľad o vašej bezpečnostnej pozícii.