Kubernetes se v podstatě stal operačním systémem cloudu. Pokud provozujete kontejnery ve velkém měřítku, téměř jistě používáte K8s. Je výkonný, flexibilní a zvládá orchestraci jako sen. Ale je tu jedna věc: stejná síla přichází s obrovským množstvím složitosti. Když přejdete z tradičního nastavení založeného na VM na kontejnerizovanou orchestraci, vaše útočná plocha se nejen posune – rozšíří se směry, na které se možná ani nedíváte.
Většina týmů začíná svou cestu s Kubernetes tím, že sleduje několik základních tutoriálů, spustí cluster na EKS, GKE nebo AKS a nasadí své aplikace. Všechno funguje. Poté přidají nějaké namespaces, několik ingress controllers a možná nějaké základní Role-Based Access Control (RBAC). Zdá se to bezpečné. Ale "funguje to" a "je to bezpečné" jsou dvě velmi odlišné věci ve světě cloud-native infrastruktury. Jediný chybně nakonfigurovaný YAML soubor nebo ServiceAccount s nadměrnými oprávněními může být rozdílem mezi bezpečným produkčním prostředím a úplným převzetím clusteru.
Zde vstupuje do hry cloud pentesting. Nemůžete jen spustit standardní síťový skener proti Kubernetes clusteru a říct, že je hotovo. K8s má vlastní interní sítě, vlastní API server a vlastní sadu zvláštností správy identit. Abyste skutečně zabezpečili cluster, musíte přemýšlet jako útočník. Musíte se zeptat: "Pokud kompromituji jeden pod, mohu se dostat k API serveru? Mohu ukrást token ze systému souborů? Mohu se laterálně přesunout do jiného namespace?"
V této příručce se ponoříme hluboko do reality zabezpečení Kubernetes. Přejdeme od obecné rady "používejte silná hesla" a podíváme se na skutečné útočné vektory, které nedají spát bezpečnostním inženýrům. A co je nejdůležitější, prozkoumáme, jak cloud-native přístup k Penetration Testing – jako to, co jsme vytvořili ve Penetrify – vám umožní najít tyto díry dříve, než to udělá někdo jiný.
Pochopení útočné plochy Kubernetes
Než budeme mluvit o tom, jak testovat cluster, musíme pochopit, co vlastně testujeme. Kubernetes není jedna jediná věc; je to kolekce komponent, které spolu musí komunikovat. Pokud je některý z těchto komunikačních kanálů otevřený nebo nesprávně ověřený, celý domeček z karet se může zhroutit.
Řídicí rovina: Mozek clusteru
Řídicí rovina je primárním cílem pro každého seriózního útočníka. Proč? Protože pokud ovládáte API server, ovládáte všechno. kube-apiserver je brána pro všechny administrativní úkoly. Pokud je vystaven veřejnému internetu bez přísné autentizace, nebo pokud je ve verzi, kterou používáte, zranitelnost, útočník může v podstatě vydávat příkazy vašemu clusteru, jako by byl administrátor.
Pak máte etcd. Toto je databáze clusteru. Ukládá všechno – secrets, config maps a stav každého podu. Pokud útočník získá přístup k etcd, nemusí ani komunikovat s API serverem; může si jen přečíst vaše secrets přímo z disku.
Worker nodes a Kubelet
Worker nodes jsou místa, kde běží váš skutečný kód. kubelet je agent běžící na každém nodu, který komunikuje zpět s řídicí rovinou. Běžnou chybou je ponechání Kubelet API otevřeného nebo povolení neověřeného přístupu. Pokud mohu komunikovat s Kubeletem, mohu být schopen spouštět příkazy uvnitř podu nebo dokonce získat citlivé informace o prostředí nodu.
Pody a kontejnery
Toto je nejběžnější vstupní bod. Většina útoků začíná zranitelností v kódu aplikace – možná RCE ve stylu Log4j nebo jednoduchá SQL Injection. Jakmile je útočník uvnitř kontejneru, začne s "pod escaping". Hledá způsoby, jak se dostat z kontejneru na hostitelský node. Odtamtud hledá ServiceAccount token obvykle připojený na /var/run/secrets/kubernetes.io/serviceaccount/token.
Síťová vrstva (CNI)
Síť Kubernetes je často ve výchozím nastavení "plochá" síť. To znamená, že ve výchozím nastavení může každý pod v clusteru komunikovat s jakýmkoli jiným podem, bez ohledu na namespace. Pokud je váš frontend webový server kompromitován, může potenciálně odesílat požadavky na vaše interní API pro zpracování plateb nebo vaši databázi bez jakéhokoli firewallu mezi nimi.
Běžné chybné konfigurace Kubernetes, které vedou k narušení bezpečnosti
Když provádíme Penetration Testing ve Penetrify, zřídka nacházíme "Zero Day" zranitelnosti v základním kódu Kubernetes. Místo toho nacházíme "Zero Day" chyby v tom, jak byl cluster nakonfigurován. To jsou nízko visící ovoce, které útočníci milují.
RBAC role s nadměrnými oprávněními
Role-Based Access Control (RBAC) je nejvíce nepochopená část zabezpečení K8s. Je velmi snadné být frustrován chybami "Permission Denied" během nasazení a jednoduše dát ServiceAccount roli cluster-admin.
Představte si jednoduchý monitorovací pod, který potřebuje pouze vypsat pody, aby zkontroloval jejich stav. Pokud je tomuto podu uděleno oprávnění cluster-admin a aplikace uvnitř něj je kompromitována, útočník má nyní plnou kontrolu nad celým clusterem. Může mazat namespaces, krást secrets a nasazovat své vlastní škodlivé pody (jako jsou crypto miners).
Past "Privileged" kontejneru
Spuštění kontejneru jako privileged: true v podstatě říká Kubernetes, aby zakázal většinu bezpečnostních hranic mezi kontejnerem a hostitelem. Privilegovaný kontejner má téměř stejný přístup k hostitelskému jádru jako proces běžící přímo na nodu. Pro pentestera je privilegovaný kontejner zlatá vstupenka. Usnadňuje únik na hostitele, což jim umožňuje přístup k Docker socketu nebo Kubelet API.
Exponovaný Dashboard a API Server
Kubernetes Dashboard je skvělý pro přehled, ale pokud není zabezpečený, je to noční můra. Viděli jsme clustery, kde byl dashboard vystaven internetu s výchozím service accountem, který měl administrátorská oprávnění. Je to v podstatě webové GUI pro zničení vaší vlastní infrastruktury. Podobně, ponechat API server otevřený pro 0.0.0.0/0 bez MFA nebo striktního IP whitelistingu je recept na katastrofu.
Nechráněné Secrets
Mnoho týmů ukládá "secrets" v objektech Kubernetes Secrets. I když to zní správně, pamatujte, že ve výchozím nastavení jsou K8s secrets pouze kódovány pomocí base64, nikoli šifrovány. Kdokoli s přístupem k API nebo databázi etcd je může dekódovat během několika sekund. Pokud nepoužíváte dedikovaný KMS (Key Management Service) nebo nástroj jako HashiCorp Vault, vaše secrets nejsou ve skutečnosti secret.
Cloud Pentesting Workflow pro Kubernetes
Tradiční Penetration Testing je často "bodový" event: konzultant přijde na dva týdny, napíše zprávu a odejde. Ale prostředí Kubernetes se mění pokaždé, když spustíte kubectl apply. Potřebujete kontinuálnější, cloud-nativní přístup k testování.
Fáze 1: Reconnaissance a External Mapping
Prvním krokem v cloudovém Penetration Testu je zjistit, co vidí svět. Začínáme skenováním odhalených endpointů.
- Je API server dostupný?
- Je otevřený port Kubelet (10250)?
- Existují nějaké odhalené dashboardy nebo stránky s metrikami Prometheus?
- Která pravidla ingress umožňují provoz do clusteru?
Fáze 2: Počáteční přístup (The "Footprint")
Jakmile najdeme vstupní bod – řekněme zranitelnou webovou aplikaci – vytvoříme si opěrný bod. To obvykle zahrnuje získání reverzního shellu. Ale jakmile jsme uvnitř, cíl se mění z "útoku na aplikaci" na "útok na cluster".
První věc, kterou pentester udělá, je zkontrolovat token ServiceAccount:
cat /var/run/secrets/kubernetes.io/serviceaccount/token
Pokud tento token existuje, můžeme jej použít k ověření na API serveru zevnitř podu.
Fáze 3: Interní Enumeration a Privilege Escalation
Nyní se ptáme: "Co s tímto tokenem vlastně můžu dělat?" Používáme nástroje jako kubectl auth can-i --list, abychom viděli naše oprávnění.
Pokud máme oprávnění k create pods, můžeme spustit "škodlivý" pod, který připojí kořenový souborový systém hostitele. Pokud máme oprávnění k get secrets, můžeme vypsat každé heslo a API klíč v namespace. Zde se odehrává "šachová partie" zabezpečení Kubernetes – přesun z podu s nízkými oprávněními na uzel s vysokými oprávněními.
Fáze 4: Lateral Movement
Pokud cluster nemá Network Policies (verze firewallu pro K8s), můžeme se pohybovat laterálně. Skenujeme interní pod síť, abychom našli další služby. Můžeme najít neověřenou mezipaměť Redis nebo interní databázi, která důvěřuje jakémukoli připojení přicházejícímu z clusteru.
Fáze 5: Exfiltrace a Persistence
Poslední fází je zjistit, zda můžeme ukrást data nebo udržet přístup. Můžeme vytvořit "zadní vrátka" Deployment, který se restartuje, pokud je smazán? Můžeme ukrást metadata IAM poskytovatele cloudu z uzlu (např. přístupem k 169.254.169.254 na AWS), abychom se přesunuli z clusteru Kubernetes do širšího účtu AWS?
Praktické kroky k posílení vašeho clusteru
Pokud jste dočetli až sem a myslíte si: "Můj cluster může být zranitelný," nepanikařte. Zabezpečení je proces neustálého zlepšování. Zde je praktický kontrolní seznam pro přesun vašeho clusteru ze "standardního" na "posílený".
1. Implementujte striktní Network Policies
Přestaňte předpokládat, že interní síť je bezpečná. Ve výchozím nastavení implementujte zásadu "deny-all" pro příchozí i odchozí provoz v rámci vašich namespaces. Poté explicitně povolte pouze připojení, která jsou nezbytná.
- Pod A by měl komunikovat pouze s Podem B na portu 8080.
- Pod B by měl komunikovat pouze s databází na portu 5432.
- Zablokujte všem podům komunikaci s cloudovým metadata API, pokud to absolutně nepotřebují.
2. Vyčistěte svůj RBAC
Proveďte audit svých rolí. Přestaňte používat cluster-admin pro všechno.
- Používejte Namespaced Roles místo ClusterRoles, kdykoli je to možné.
- Dodržujte princip nejmenšího privilegia (PoLP). Pokud pod potřebuje pouze číst ConfigMap, nedávejte mu možnost ji aktualizovat.
- Pravidelně kontrolujte, kdo má přístup ke clusteru, pomocí nástrojů jako
rbac-lookup.
3. Používejte Pod Security Admissions (PSA)
Přestaňte povolovat privilegované kontejnery. Kubernetes má vestavěné Pod Security Admissions, které vám umožňují vynutit různé úrovně zabezpečení:
- Privileged: Neomezené (v podstatě "dělejte, co chcete"). Vyhněte se tomu v produkci.
- Baseline: Zabraňuje známým eskalacím privilegií.
- Restricted: Vynucuje velmi vysoký standard zabezpečení (žádní root uživatelé, žádný přístup k hostitelské síti).
Snažte se dosáhnout profilu restricted pro všechny vaše aplikační workloady.
4. Zabezpečte své Secrets
Odstupte od K8s secrets kódovaných pomocí base64.
- Povolte Encryption at Rest pro vaši databázi
etcd. - Použijte cloud-nativní secret manager. Například použijte AWS Secrets Manager nebo Azure Key Vault a integrujte je se svými pody pomocí Secret Store CSI Driver. Tím zajistíte, že secrets budou vloženy do podu za běhu a nikdy nebudou uloženy jako prostý text v K8s API.
5. Udržujte své komponenty aktualizované
Zní to jednoduše, ale zde dochází k mnoha narušením. Zranitelnosti v kube-apiserver nebo kubelet jsou rychle opraveny, ale pokud používáte verzi starou dva roky, jste snadný cíl. Automatizujte upgrady clusteru, abyste měli aktuální informace o nejnovějších bezpečnostních záplatách.
Srovnání: Manuální Penetration Testing vs. Automatizované skenování vs. Cloud-nativní platformy
Mnoho lidí se ptá: "Nemůžu jen spustit skener zranitelností?" Odpověď je ano, ale skener není Penetration Test. Zde je rozdíl.
| Funkce | Automatizovaný skener zranitelností | Tradiční manuální Penetration Testing | Cloud-nativní platforma (Penetrify) |
|---|---|---|---|
| Rozsah | Najde známé CVE v balíčcích. | Hloubková analýza logiky a konfigurace. | Kombinuje skenování CVE s analýzou konfigurace. |
| Kontext | Nerozumí RBAC nebo síťovému toku. | Rozumí kontextu, ale je pomalý. | Mapuje útočný povrch v reálném čase. |
| Frekvence | Může běžet denně. | Jednou nebo dvakrát ročně. | Průběžně a na vyžádání. |
| Akceschopnost | Poskytuje dlouhý seznam "potenciálních" chyb. | Poskytuje podrobnou zprávu. | Poskytuje cesty k nápravě a integruje se s SIEM. |
| Cena | Nízká až střední. | Vysoká (poplatky konzultantům). | Škálovatelné předplatné. |
Skenery jsou skvělé pro nalezení verze Nginx, která má chybu. Ale skener vám neřekne, že vaše RBAC politika umožňuje podu vývojáře smazat vaši produkční databázi. Manuální pentester to najde, ale jsou drazí a nemohou být všude najednou.
Platforma jako Penetrify překlenuje tuto mezeru. Využívá cloud-nativní architekturu k automatické a konzistentní simulaci těchto útoků, čímž vám poskytuje hloubku Penetration Testu s rychlostí skeneru.
Pokročilý scénář: Únik "Pod-to-Cloud"
Abyste skutečně pochopili, proč je cloudový Penetration Testing odlišný, podívejme se na realistický scénář útoku. Toto je běžná cesta, kterou nacházíme během hodnocení.
Krok 1: Vstup Útočník najde zranitelnost Server-Side Request Forgery (SSRF) ve veřejně přístupné aplikaci Django běžící v Kubernetes podu.
Krok 2: Získání metadat
Útočník používá SSRF k zasažení koncového bodu metadat poskytovatele cloudu: http://169.254.169.254/latest/meta-data/iam/security-credentials/. Protože role IAM uzlu má nadměrná oprávnění, útočník získá dočasný přístupový klíč AWS.
Krok 3: Skenování účtu
Pomocí těchto klíčů si útočník uvědomí, že má oprávnění S3:ListBucket a S3:GetObject pro celý účet AWS. Najdou bucket obsahující zálohy produkční databáze.
Krok 4: Převzetí kontroly nad clusterem
Při prohledávání S3 bucketu najdou zálohu souboru kubeconfig, který byl omylem nahrán. Tento soubor obsahuje certifikát pro uživatele cluster-admin.
Krok 5: Totální kontrola
Útočník používá kubeconfig pro připojení k API serveru ze svého vlastního notebooku. Nyní má absolutní moc nad clusterem. Nasadí šifrovaný tunel (jako Ngrok) uvnitř clusteru, aby si udržel trvalá zadní vrátka, obcházející všechny perimetrické firewally.
Ponaučení? Zranitelnost nebyla jen v aplikaci Django. Byla to řetěz: SSRF $\rightarrow$ Nadměrná oprávnění Node IAM $\rightarrow$ Uniklé tajemství v S3 $\rightarrow$ Admin Kubeconfig. Jednoduchý skener podů by našel pouze zranitelnost Django; neukázal by vám, že je ohrožen celý váš účet AWS.
Integrace zabezpečení do CI/CD Pipeline (DevSecOps)
Nemůžete jen "dělat" zabezpečení na konci. V době, kdy pentester najde díru ve vašem produkčním clusteru, je škoda (nebo náklady na její opravu) již vysoká. Musíte posunout zabezpečení "vlevo".
Shift-Left Testing
Integrujte bezpečnostní kontroly do svých GitLab nebo GitHub pipelines.
- Statická analýza (SAST): Skenujte své Dockerfiles pro "USER root" a své YAML soubory pro
privileged: true. - Skenování obrazů: Používejte nástroje k zajištění, že vaše základní obrazy nemají známé CVE, než se vůbec dostanou do registru.
- Policy as Code: Používejte OPA (Open Policy Agent) nebo Kyverno. Tyto nástroje fungují jako admission controllers. Pokud se vývojář pokusí nasadit pod, který nemá limity zdrojů nebo běží jako root, cluster jednoduše odmítne nasazení.
Zpětnovazební smyčka
Skutečná magie se stane, když propojíte výsledky Penetration Testingu zpět do svého vývojového cyklu. Když platforma jako Penetrify identifikuje chybnou konfiguraci ve vašem vývojovém clusteru, tento poznatek by měl automaticky vytvořit ticket v Jiře pro tým, aby to opravil.
Zabezpečení by nemělo být "brána", která zastaví nasazení; mělo by to být "svodidlo", které nasazení vede. Když vývojáři přesně vědí, proč je určitá konfigurace nebezpečná (protože Penetration Test simuloval útok a dokázal to), je mnohem pravděpodobnější, že od začátku napíší bezpečný kód.
Běžné chyby při zabezpečení Kubernetes
I zkušení týmy na tom pohoří. Pokud spravujete cluster, zkontrolujte, zda neděláte některou z těchto věcí.
Chyba 1: Důvěra označení "Cloud Managed"
Mnoho lidí předpokládá, že protože používají EKS nebo GKE, Google nebo Amazon se starají o zabezpečení. Zatímco poskytovatel cloudu zabezpečuje řídicí rovinu (hlavní uzly), vy jste stále zodpovědní za datovou rovinu (vaše pracovní uzly, vaše pody a vaše síťové politiky). "Shared Responsibility Model" je skutečný. Pokud necháte svůj API server otevřený, AWS nezabrání útočníkovi ve vstupu.
Chyba 2: Ignorování "výchozího" jmenného prostoru
Jmenný prostor default je často odkladištěm pro testy a náhodné pody. Mnoho týmů zapomíná aplikovat stejné přísné RBAC a síťové politiky na jmenný prostor default jako na production. Útočník, který se dostane do "testovacího" podu v jmenném prostoru default, jej často může použít jako výchozí bod k útoku na jiné části clusteru.
Chyba 3: Přílišné spoléhání se na skenování obrazů
Skenování obrazu na CVE je důležité, ale nestačí to. Obraz může mít nulový počet známých zranitelností, ale stále může být nakonfigurován tak, aby běžel jako root s plným přístupem k PID jmennému prostoru hostitele. Musíte zabezpečit konfiguraci běhu, nejen binárku.
Chyba 4: Selhání v protokolování a monitorování
Nemůžete zastavit útok, který nevidíte. Mnoho týmů zapomíná povolit Kubernetes Audit Logs. Auditní protokoly vám řeknou, kdo co udělal, kdy a jak. Bez nich, pokud útočník ukradne token a vytvoří backdoor, nebudete mít žádný záznam o tom, jak se to stalo.
FAQ: Zabezpečení Kubernetes pomocí cloudového Penetration Testing
Otázka: Jak často bych měl provádět Penetration Test na svém Kubernetes clusteru? Odpověď: Záleží na vaší frekvenci změn. Pokud denně nahráváte kód, Penetration Test jednou ročně je zbytečný. Měli byste mít automatizované skenování denně a hloubkové Penetration Testing čtvrtletně nebo po každé zásadní architektonické změně. Cloud-nativní platformy umožňují "kontinuální Penetration Testing," což je zlatý standard.
Otázka: Potřebuji instalovat agenty na své nody pro cloudový Penetration Testing? Odpověď: Ne nutně. Mnoho moderních platforem, včetně Penetrify, používá kombinaci skenování založeného na API a řízených "útočných podů" k simulaci hrozeb, aniž by bylo nutné instalovat invazivní agenty na každý jednotlivý node. To snižuje režii na výkon a bezpečnostní riziko samotného testovacího nástroje.
Otázka: Může Penetration Testing poškodit můj produkční cluster? Odpověď: Vždy existuje riziko u jakéhokoli aktivního testování. Proto doporučujeme testovat v stagingovém prostředí, které zrcadlí produkci. Nicméně, profesionální cloudové nástroje pro Penetration Testing jsou navrženy tak, aby byly nedestruktivní. Hledají "proof of concept" přístup (jako čtení souboru) spíše než provádění útoků typu "denial of service".
Otázka: Jaký je rozdíl mezi skenováním zranitelností a Penetration Test? Odpověď: Skenování je jako domácí bezpečnostní systém, který kontroluje, zda jsou dveře zamčené. Penetration Test je jako najmout si někoho, aby se skutečně pokusil vloupat do vašeho domu. Skener vám řekne, že dveře mohou být otevřené; pentester skutečně projde dveřmi a řekne vám, že se může dostat k vaší šperkovnici v ložnici.
Otázka: Stačí RBAC k zabezpečení clusteru? Odpověď: Ne. RBAC je jen jedna vrstva. Potřebujete také Network Policies (k zastavení laterálního pohybu), Pod Security Admissions (k zastavení úniků) a Secret Management (k ochraně citlivých dat). Berte to jako "defense in depth."
Závěrečné poznatky a další kroky
Zabezpečení Kubernetes není o zaškrtnutí jednoho políčka; je to o snížení "blast radius." Musíte předpokládat, že v určitém okamžiku bude pod kompromitován. Cílem je zajistit, aby se útočník v takovém případě ocitl v zamčené místnosti bez klíčů a bez možnosti komunikovat se zbytkem domu.
Pokud se cítíte zahlceni, začněte těmito třemi okamžitými akcemi:
- Zkontrolujte svůj RBAC: Najděte každý ServiceAccount s
cluster-admina zjistěte, zda ho skutečně potřebuje. (Nápověda: Pravděpodobně ne). - Povolte Network Policies: Začněte blokováním veškerého odchozího provozu z vašich podů do cloudového metadata API (
169.254.169.254). - Spusťte skutečný test: Přestaňte hádat, jestli jste zabezpečeni. Použijte nástroj nebo službu k simulaci útoku.
Složitost Kubernetes je jeho největší silou, ale také jeho největší slabinou. Jediný způsob, jak skutečně znát svou pozici, je otestovat ji v reálných podmínkách.
Pokud chcete přestat hádat a začít vědět, Penetrify vám může pomoci. Poskytujeme cloud-nativní infrastrukturu pro spouštění bezpečnostních hodnocení na profesionální úrovni bez masivní režie tradičního poradenství. Pomůžeme vám najít mezery ve vašem RBAC, díry ve vašich Network Policies a cesty k eskalaci privilegií dříve, než to udělá škodlivý aktér.
Nečekejte na narušení, abyste zjistili, že váš "zabezpečený" cluster měl dokořán otevřené dveře. Navštivte Penetrify.cloud ještě dnes a získejte jasný, akční pohled na své bezpečnostní postavení.