Jak opravit běžné chybné konfigurace v Kubernetes clusterech

Pravděpodobně jste slyšeli vtip, že Kubernetes je v podstatě obrovská hromada YAML souborů držená pohromadě nadějí a několika velmi vystresovanými SRE. I když je to trochu nadsázka, vystihuje to základní pravdu: Kubernetes je neuvěřitelně komplexní. Je to výkonný orchestrátor, ale tato síla přichází se strmou křivkou učení. Když se pohybujete rychle – nasazujete aktualizace několikrát denně, škálujete pody napříč regiony a spravujete service meshe – je téměř nevyhnutelné, že něco bude chybně nakonfigurováno.

Problém je v tom, že v cloud-native prostředí může drobná překlep v manifestu nebo „dočasná“ úprava oprávnění otevřít masivní díru ve vaší bezpečnosti. Všichni jsme to zažili. Jen jste chtěli, aby se pod spustil, takže jste mu udělili cluster-admin oprávnění „jen na vteřinu“, abyste vyřešili problém s připojením. Pak jste na to zapomněli. O šest měsíců později tento pod stále běží a je nyní zlatou vstupenkou pro každého útočníka, kterému se podaří získat shell uvnitř vašeho kontejneru.

Oprava běžných chybných konfigurací v Kubernetes clusterech není jen o spuštění bezpečnostního skeneru a odškrtávání políček. Jde o pochopení „proč“ za riziky. Pokud nerozumíte tomu, jak privilegovaný kontejner může vést k úplnému průlomu uzlu (node breakout), budete stále dělat stejné chyby pokaždé, když napíšete nový deployment soubor.

V tomto průvodci projdeme nejčastější chyby, které vidíme v praxi, a co je důležitější, přesně jak je opravit. Podíváme se na vše od nočních můr Role-Based Access Control (RBAC) po nebezpečí výchozího jmenného prostoru (default namespace). Na konci byste měli mít jasný plán pro zabezpečení vašeho clusteru, aniž byste narušili vaše aplikace.

Nebezpečí nadměrně privilegovaných Service Accountů (RBAC)

Role-Based Access Control (RBAC) je srdcem bezpečnosti Kubernetes. Určuje, kdo co může dělat a kde. Nicméně, RBAC je místo, kde většina lidí začíná dělat kompromisy. Když vývojář řekne: „Nemůžu dostat svou CI/CD pipeline k nasazení aplikace,“ nejjednodušší řešení je často udělit service accountu cluster-admin oprávnění.

Funguje to. Pipeline zezelená. Všichni jsou šťastní. Ale právě jste vytvořili masivní zranitelnost. Pokud dojde k úniku vašeho CI/CD secretu, útočník nemá přístup jen k jedné aplikaci; má klíče k celému vašemu království.

Past „Cluster-Admin“

Role cluster-admin je vestavěná ClusterRole, která poskytuje neomezený přístup ke každému zdroji v clusteru. Používání této role pro service accounty na úrovni aplikací je kardinální hřích bezpečnosti K8s.

Řešení: Princip nejmenších oprávnění (PoLP) Místo používání širokých rolí je třeba definovat specifické role, které povolují pouze přesně požadované akce.

Například, pokud pod potřebuje pouze číst ConfigMapy ve svém vlastním jmenném prostoru, aby se spustil, nedávejte mu ClusterRole. Dejte mu Role (která je vázaná na jmenný prostor) pouze s operacemi get a list pro configmaps.

Příklad zpřísněné Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app-namespace
  name: config-reader
rules:
- apiGroups: [""] 
  resources: ["configmaps"]
  verbs: ["get", "list"]

Vyhýbání se výchozímu Service Accountu

Ve výchozím nastavení má každý jmenný prostor service account s názvem default. Pokud pro pod nespecifikujete service account, Kubernetes mu přidělí tento. Historicky měl výchozí service account široká oprávnění. Zatímco moderní verze jsou lepší, mnoho starších clusterů má stále účet default vázaný na příliš benevolentní role.

Řešení: Explicitní účty služeb Nikdy se nespoléhejte na výchozí nastavení. Vytvořte vyhrazený účet služby pro každou jednotlivou aplikaci.

Vytvořte ServiceAccount.
Vytvořte Role s minimálními nezbytnými oprávněními.
Vytvořte RoleBinding pro propojení těchto dvou.
Explicitně nastavte serviceAccountName ve specifikaci vašeho Podu.

Pokud vaše aplikace vůbec nepotřebuje komunikovat s Kubernetes API (což platí pro většinu webových aplikací), jděte ještě o krok dál. Nastavte automountServiceAccountToken: false ve specifikaci vašeho podu. Tím se zabrání připojení tokenu API do podu, což znamená, že i když se útočník dostane dovnitř, nebude mít žádný token, který by mohl použít k laterálnímu pohybu v rámci clusteru.

Zpřísnění bezpečnostního kontextu podu

Když se kontejner spustí, neběží jen „v“ clusteru; běží jako proces na uzlu Linuxu. Pokud tento proces běží jako uživatel root a existuje zranitelnost v běhovém prostředí kontejneru nebo v jádře, útočník může potenciálně „uniknout“ z kontejneru a získat root přístup k hostitelskému stroji. Toto je známé jako únik z kontejneru.

Problém s nastavením „Privileged: True“

V souborech YAML často uvidíte privileged: true. To v podstatě říká Kubernetes, aby kontejneru udělil téměř všechny schopnosti hostitelského stroje. Pro standardní aplikace je to zřídka nutné. Obvykle je to potřeba pouze pro specializované systémové nástroje (jako jsou CNI pluginy nebo ovladače úložiště).

Řešení: Přestaňte používat privilegovaný režim Pokud zjistíte, že potřebujete privileged: true, zeptejte se proč. Potřebujete jen změnit nastavení sítě? Potřebujete připojit konkrétní zařízení?

Místo plného privilegovaného režimu použijte capabilities. Linuxové `capabilities` vám umožňují rozdělit „root“ oprávnění na menší části. Například, pokud potřebujete pouze upravit síťová rozhraní, použijte CAP_NET_ADMIN namísto udělení plného root přístupu podu.

Spouštění jako root

Mnoho Docker image je ve výchozím nastavení vytvořeno tak, aby běžely jako root. Pokud je nasadíte tak, jak jsou, váš proces běží s UID 0. To představuje obrovské riziko.

Řešení: Použijte uživatele bez oprávnění root Měli byste vynutit spouštění bez oprávnění root jak v Dockerfile, tak v Kubernetes securityContext.

Do vašeho deployment YAML přidejte sekci securityContext:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000

runAsNonRoot: true říká Kubernetes, aby zkontroloval, zda se image pokouší spustit jako root, a v takovém případě spuštění selhal. To nutí váš tým vytvářet image s vyhrazeným uživatelem (např. USER 1000 v Dockerfile).

Souborové systémy root pouze pro čtení

Většina aplikací ve skutečnosti nepotřebuje zapisovat do svého vlastního root souborového systému. Zapisují do logů (které by měly jít na stdout/stderr) nebo do připojených svazků. Pokud útočník získá přístup ke kontejneru, první věc, kterou obvykle udělá, je stažení sady nástrojů nebo skriptu na lokální disk. Pokud je souborový systém pouze pro čtení, tento vektor útoku je zablokován.

Řešení: Nastavte readOnlyRootFilesystem na true

securityContext:
  readOnlyRootFilesystem: true

Pokud vaše aplikace potřebuje zapisovat do dočasných souborů, nevypínejte souborový systém pouze pro čtení. Místo toho připojte svazek emptyDir do konkrétní cesty, kam aplikace potřebuje zapisovat (například `/tmp`).

Správa vaší útočné plochy: Síťové politiky

Ve výchozím nastavení má Kubernetes "plochou" síť. To znamená, že jakýkoli pod v jakémkoli jmenném prostoru může komunikovat s jakýmkoli jiným podem v jakémkoli jiném jmenném prostoru. I když je to skvělé pro konektivitu, pro bezpečnost je to noční můra. Pokud je váš frontendový webový server kompromitován, útočník může volně skenovat vaši interní síť a najít vaši databázi, vaši cache a vaše interní administrátorské nástroje.

Nedostatek segmentace

Představte si dům, kde mezi místnostmi nejsou žádné dveře – jen jeden velký otevřený prostor. Pokud se zloděj dostane přes přední okno, má okamžitý přístup do ložnice, kuchyně a k trezoru. Přesně tak funguje výchozí K8s cluster.

Řešení: Implementujte politiku výchozího zamítnutí Nejbezpečnější způsob, jak spravovat síťový provoz, je začít blokováním všeho a poté explicitně povolit pouze to, co je nezbytné. Toto je přístup "Zero Trust".

Nejprve vytvořte politiku, která zahodí veškerý příchozí (ingress) a odchozí (egress) provoz pro daný jmenný prostor:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Jakmile je vše zablokováno, vytvoříte specifická pravidla "povolení". Například, pokud váš pod frontend potřebuje komunikovat s vaším podem backend na portu 8080, napíšete politiku, která specificky povolí provoz z labelu frontend na label backend na tomto portu.

Kontrola odchozího provozu (Egress)

Většina lidí se zaměřuje na to, kdo se může dostat do jejich clusteru, ale zapomínají na to, co jde ven. Pokud je pod kompromitován, útočník se pokusí "zavolat domů" na server pro velení a řízení (C2), aby obdržel instrukce nebo exfiltroval data.

Řešení: Omezte odchozí provoz (Egress) Pokud váš pod nepotřebuje komunikovat s veřejným internetem (což je u backendové služby vzácné), zablokujte veškerý odchozí provoz (egress). Pokud internetový přístup potřebuje (např. pro volání API třetí strany, jako je Stripe nebo Twilio), použijte service mesh jako Istio nebo Linkerd, nebo použijte Egress Gateway k povolení specifických externích domén.

Past "jednorázového testování" a kontinuální testování

Jedna z největších chybných konfigurací není řádek kódu – je to proces. Mnoho společností provádí "bezpečnostní audit" jednou za čtvrtletí. Najmou firmu, firma najde deset chybných konfigurací, tým je opraví a všichni si oddechnou.

Prostředí Kubernetes jsou však dynamická. Zítra můžete změnit ConfigMap, aktualizovat Helm chart nebo přidat nový sidecar kontejner. Ten "čistý" audit z minulého měsíce je nyní irelevantní. Tomu říkáme "jednorázová" bezpečnost a v cloud-native světě je to nebezpečné.

Zde se stává nezbytným posun směrem k řízení kontinuální expozice hrozbám (CTEM). Nemůžete jen skenovat zranitelnosti; musíte simulovat, jak se útočník skutečně pohybuje vaším clusterem.

Pokud máte pod s příliš permisivní rolí RBAC a chybně nakonfigurovanou Network Policy, jednoduchý sken zranitelností je může označit jako dvě samostatná "střední" rizika. Ve skutečnosti však společně vytvářejí "kritickou" cestu: útočník zneužije webovou zranitelnost, použije roli RBAC k vypsání tajemství, najde heslo k databázi a použije otevřenou síť k vyhození vašich dat.

Nástroje jako Penetrify pomáhají překlenout tuto mezeru. Namísto statické zprávy, která se jen povaluje, Penetrify poskytuje bezpečnostní testování na vyžádání, které se škáluje s vaším cloudovým prostředím. Pomáhá vám identifikovat tyto "řetězce" chybných konfigurací – způsob, jakým se malá chyba RBAC kombinuje se síťovou mezerou – dříve, než to udělá škodlivý aktér. Přechodem k modelu "Penetration Testing as a Service" (PTaaS) přestanete hádat, zda je váš cluster zabezpečený, a začnete to vědět.

Zabezpečení API serveru a řídicí roviny

API server je mozkem vašeho clusteru. Vše – od příkazů kubectl po interní logiku kontrolerů – prochází jím. Pokud je API server vystavený nebo chybně nakonfigurovaný, celý váš cluster je kompromitován.

Veřejně přístupné API servery

Ve spěchu se spuštěním clusteru některé týmy nechávají API server otevřený celému internetu. I když je chráněn autentizací, vystavení koncového bodu umožňuje útočníkům pokoušet se o útoky hrubou silou, zneužívat Zero Day zranitelnosti v samotném API serveru nebo provádět útoky typu denial-of-service.

Řešení: Použijte soukromé koncové body a autorizované sítě Pokud používáte spravovanou službu jako EKS, GKE nebo AKS, povolte možnost "Soukromý cluster". Tím zajistíte, že API server je přístupný pouze z vašeho VPC nebo přes VPN/Bastion hosta. Pokud jej musíte ponechat veřejný, použijte "Autorizované sítě" (whitelisting IP adres) k omezení přístupu pouze na IP adresu vaší kanceláře nebo IP adresy vašich CI/CD runnerů.

Anonymní autentizace

Některé starší clustery nebo vlastní instalace mohou mít povolenou anonymní autentizaci. To umožňuje, aby požadavky na API server, které nejsou autentizovány, byly považovány za speciálního uživatele system:anonymous. V závislosti na vašich nastaveních RBAC může mít tento uživatel náhodou oprávnění k prohlížení podů nebo uzlů.

Řešení: Zakažte anonymní autentizaci Ujistěte se, že je na vašem kube-apiserveru nastaven příznak --anonymous-auth=false. Pokud jej z nějakého důvodu nemůžete zakázat, ujistěte se, že uživatel system:anonymous není vázán na žádné role, které poskytují informace o vašem clusteru.

Zabezpečení Etcd

Etcd je databáze, kde Kubernetes ukládá veškerý svůj stav. Pokud útočník získá přístup k etcd, má vše: každé tajemství, každou konfiguraci a schopnost modifikovat stav clusteru, aniž by procházel přes API server.

Řešení: Šifrujte a izolujte etcd

Šifrování v klidu: Povolte šifrování pro tajemství v etcd, aby v případě krádeže nebo přístupu k disku byla tajemství k ničemu.
Vzájemné TLS (mTLS): Zajistěte, aby API server a etcd komunikovaly pomocí certifikátů. Nikdo by neměl být schopen komunikovat s etcd bez platného klientského certifikátu.
Síťová izolace: etcd by mělo být na zcela oddělené síti nebo chráněno přísnými pravidly firewallu, aby k němu měl přístup pouze API server.

Správa tajemství bez „tajemství“

Název Secret v Kubernetes je tak trochu lež. Ve výchozím nastavení jsou Kubernetes tajemství pouze kódována base64, nikoli šifrována. Kdokoli s přístupem k API nebo záloze etcd může dekódovat vaše heslo k databázi přibližně za dvě sekundy pomocí jednoduchého terminálového příkazu: echo "base64-string" | base64 --decode.

Ukládání tajemství v Gitu (Největší hřích)

Děje se to častěji, než si lidé připouštějí. Vývojář vloží soubor secret.yaml do Git repozitáře "jen na pár minut", aby pomohl kolegovi, a pak jej zapomene smazat. Nyní toto heslo žije v historii Gitu navždy.

Řešení: Externí správa tajemství Přestaňte používat nativní K8s tajemství pro citlivá data. Místo toho použijte vyhrazeného správce tajemství.

HashiCorp Vault: Průmyslový standard. Poskytuje dynamické tajné klíče a přísnou kontrolu přístupu.
AWS Secrets Manager / Azure Key Vault / GCP Secret Manager: Skvělé, pokud jste již vázáni na konkrétního poskytovatele cloudu.

Pro integraci těchto nástrojů s Kubernetes použijte nástroje jako External Secrets Operator (ESO) nebo Secrets Store CSI Driver. Tyto nástroje načítají tajný klíč z externího trezoru a vkládají jej do podu jako svazek nebo dočasný tajný klíč K8s, čímž zajišťují, že skutečný "zdroj pravdy" nikdy nebude uložen ve vašich YAML souborech nebo Gitu.

Rotace tajných klíčů

Většina týmů nastaví heslo a nechá ho po dobu tří let. Pokud dojde k úniku tohoto hesla, útočník má trvalá zadní vrátka.

Řešení: Automatická rotace Pokud používáte externího správce, jako je Vault, můžete implementovat automatickou rotaci. Správce tajných klíčů aktualizuje heslo v databázi a poté aktualizuje hodnotu v Kubernetes. Protože aplikace čte tajný klíč ze svazku nebo přes API, převezme nové heslo bez nutnosti kompletního opětovného nasazení.

Omezení zdrojů a problém "hlučného souseda"

Ačkoli se nejedná o "bezpečnostní" chybnou konfiguraci v tradičním smyslu, nenastavení limitů zdrojů představuje riziko pro stabilitu a dostupnost. V Kubernetes, pokud se jeden pod vymkne kontrole a začne spotřebovávat veškeré CPU nebo RAM na uzlu, může to „vyhladovět“ ostatní pody – včetně kritických systémových komponent – což vede k pádu uzlu. Jedná se v podstatě o samo-způsobené odepření služby (DoS).

Nebezpečí "neomezených" podů

Pokud nedefinujete resources.limits, pod může využívat tolik zdrojů uzlu, kolik chce. Pokud máte ve své aplikaci únik paměti, bude pomalu spotřebovávat veškerou RAM na uzlu, dokud Linux OOM (Out of Memory) killer nezačne ukončovat procesy. Problém? OOM killer může nejprve ukončit váš nejdůležitější pod.

Řešení: Nastavte požadavky a limity Každý kontejner by měl mít request (co potřebuje ke spuštění) a limit (maximum, které smí použít).

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

Požadavky: Používá plánovač k nalezení uzlu s dostatečným prostorem.
Limity: Vynucovány runtime kontejneru, aby se zabránilo podu zabírat celý uzel.

Řešení omezování CPU

Buďte opatrní s limity CPU. Na rozdíl od paměti (kde dosažení limitu ukončí pod), dosažení limitu CPU pod pouze „omezí“ (throttles). Vaše aplikace se zpomalí, ale nespadne. Pokud ve svých aplikacích zaznamenáte vysokou latenci, zkontrolujte metriky Prometheus pro omezování CPU. Možná budete muset zvýšit své limity nebo optimalizovat kód.

Zabezpečení obrazů a rizika dodavatelského řetězce

Váš cluster je tak bezpečný, jako obrazy, které v něm spouštíte. Pokud stahujete my-app:latest z veřejného registru, v podstatě spouštíte kód napsaný cizí osobou na vaší produkční infrastruktuře.

Používání tagu `:latest`

Používání :latest je recept na katastrofu. Nemáte tušení, jaká verze kódu se skutečně spouští. Když se pod restartuje, může stáhnout novou verzi obrazu, která obsahuje zásadní změnu, nebo, což je horší, škodlivý payload.

Řešení: Používejte neměnné tagy nebo digest Vždy používejte specifický tag verze (např. my-app:v1.2.3) nebo, pro maximální bezpečnost, SHA256 digest obrazu. To zajišťuje, že pokaždé budou nasazeny přesně stejné bajty.

Spouštění obrazů z nedůvěryhodných registrů

Veřejné registry jsou plné "typo-squatted" obrazů – obrazů, které vypadají jako populární, ale obsahují malware.

Řešení: Soukromý registr a skenování obrazů

Používejte soukromý registr: Stahujte veřejné obrazy, skenujte je a poté je nahrajte do vlastního soukromého registru (například ECR, ACR nebo Harbor).
Automatizované skenování: Použijte skener jako Trivy nebo Clair pro kontrolu známých CVE (Common Vulnerabilities and Exposures) ve vašich obrazech.
Admission controllery: Použijte nástroj jako Kyverno nebo OPA (Open Policy Agent), abyste zabránili nasazení jakéhokoli obrazu, pokud nebyl naskenován nebo pokud obsahuje „kritické“ zranitelnosti.

Komplexní kontrolní seznam pro zabezpečení Kubernetes

Aby to bylo použitelné v praxi, zde je souhrnný kontrolní seznam, který můžete použít během vašeho dalšího sprintu nebo bezpečnostní revize.

RBAC a přístup

Žádné servisní účty s oprávněním cluster-admin (pokud to není naprosto nezbytné).
Žádné aplikace nepoužívají `default` servisní účet.
`automountServiceAccountToken: false` nastaveno pro pody, které nepotřebují přístup k API.
API Server není otevřený veřejnému internetu.
Anonymní autentizace je zakázána na API serveru.

Zabezpečení podů

`privileged: true` je zakázáno pro aplikační pody.
`runAsNonRoot: true` a `runAsUser` jsou definovány pro všechny kontejnery.
`readOnlyRootFilesystem: true` je povoleno, kde je to možné.
CPU a paměťové `limits` a `requests` jsou nastaveny pro každý kontejner.

Síťová bezpečnost

Je zavedena `default-deny-all` NetworkPolicy pro každý jmenný prostor.
Používají se explicitní pravidla „Allow“ pro nezbytný provoz mezi službami.
Odchozí provoz je omezen na známé, požadované koncové body.

Data a tajemství

Žádná tajemství nejsou uložena v Git repozitářích.
Tajemství jsou spravována prostřednictvím externího trezoru (Vault, AWS SM atd.).
Tajemství jsou šifrována v klidu v etcd.
etcd je izolováno a vyžaduje mTLS pro komunikaci.

Dodavatelský řetězec

Obrazy jsou stahovány ze soukromého, důvěryhodného registru.
Žádné obrazy nepoužívají tag `latest` v produkci.
Všechny obrazy jsou skenovány na CVE před nasazením.
Admission controller blokuje nevyhovující obrazy.

Běžné scénáře chybné konfigurace: Před a po

Abychom vám poskytli jasnější představu o tom, jak tato řešení vypadají v praxi, podívejme se na několik scénářů „Před a po“.

Scénář 1: „Líné“ nasazení

Před: Vývojář nasadí jednoduché Node.js API. Používá výchozí servisní účet, běží jako root, nemá žádné limity zdrojů a žádné síťové politiky.

Riziko: Zranitelnost v balíčku Node.js umožní útočníkovi získat shell. Jelikož je root a má výchozí token, může prozkoumat interní síť, najít databázi a potenciálně eskalovat oprávnění na uzel.

Po:

Použijte vlastní ServiceAccount bez oprávnění k API.
Nastavte runAsNonRoot: true.
Definujte limity cpu a memory.
Aplikujte NetworkPolicy, která povoluje provoz pouze z Ingress Controlleru.
Výsledek: I když útočník získá shell, je uživatelem s nízkými oprávněními, nemůže komunikovat s jinými pody a nemůže shodit node spotřebováním veškeré RAM.

Scénář 2: Únik "Secretu"

Předtím: Tým ukládá heslo k databázi do Kubernetes Secretu vytvořeného z lokálního YAML souboru. YAML soubor byl omylem commitován do feature branche.

Riziko: Kdokoli s oprávněním ke čtení Git historie má nyní heslo k produkční databázi.

Poté:

Přesuňte heslo do AWS Secrets Manageru.
Nainstalujte External Secrets Operator.
K8s secret je nyní "stínem" AWS secretu a nikdy není uložen v Gitu.
Výsledek: Secret je centralizovaný, automaticky rotovaný a nikdy se nedotkne lokálního disku vývojáře v plain textu.

Často kladené otázky (FAQ)

1. Nezpůsobí nastavení limitů zdrojů pád mých podů?

Ano, pokud nastavíte limit memory příliš nízko, váš pod bude OOMKilled. To je ve skutečnosti dobrá věc – je lepší, aby jeden pod spadl a restartoval se, než aby jeden pod shodil celý váš fyzický node. Trik spočívá v monitorování skutečného využití vaší aplikace pomocí nástrojů jako Prometheus a Grafana a následném nastavení limitů mírně nad špičkové využití.

2. Je skutečně nutné používat Service Mesh pro síťovou bezpečnost?

Pro malé clustery může být Service Mesh (jako Istio) přehnaný. Standardní Kubernetes NetworkPolicies obvykle stačí k dosažení 80 % cíle. Pokud však potřebujete pokročilé funkce, jako je mutual TLS (mTLS) mezi všemi službami nebo komplexní traffic splitting, je service mesh správným krokem.

3. Jak najdu všechny své aktuální chybné konfigurace, aniž bych kontroloval každý YAML soubor?

Dělat to ručně je nemožné, jakmile máte více než několik aplikací. Měli byste použít automatizované nástroje. Nástroje jako kube-bench (který kontroluje proti CIS benchmarks) a kube-hunter jsou skvělé pro hledání děr. Pro kontinuálnější "pohled útočníka" na váš cluster může platforma jako Penetrify automaticky mapovat vaši attack surface a najít cesty, kterými by se útočník skutečně vydal.

4. Funguje `runAsNonRoot`, pokud byl image sestaven jako root?

Pokud nastavíte runAsNonRoot: true a metadata image říkají, že běží jako root (UID 0), Kubernetes odmítne spustit pod. Musíte se vrátit k Dockerfile a přidat uživatele (např. RUN useradd -u 1000 appuser && USER appuser).

5. Mohu aplikovat tato bezpečnostní nastavení na existující cluster bez downtime?

Ano, ale dělejte to opatrně. Neaplikujte default-deny-all network policy na celý váš produkční namespace najednou, jinak shodíte celý váš web. Aplikujte policy jednu službu po druhé. Podobně otestujte změny securityContextu ve staging prostředí, abyste zajistili, že vaše aplikace nepotřebuje specifické root oprávnění k zápisu do složky.

Přechod od reaktivní k proaktivní bezpečnosti

Opravování chybných konfigurací je neustálý boj. Jak přidáváte více služeb, více vývojářů a složitější integrace, "security surface" vašeho clusteru roste. Pokud se spoléháte na manuální checklist nebo jednou ročně prováděný audit, v podstatě hrajete hru whack-a-mole, kde krtek má raketomet.

Cílem by mělo být přejít z reaktivního stavu – kdy věci opravujete poté, co jsou nahlášeny – do stavu proaktivního. To znamená integrovat zabezpečení do vašeho CI/CD pipeline (DevSecOps) a používat kontinuální testování.

Automatizace je jediný způsob, jak držet krok s rychlostí Kubernetes. Když můžete automaticky skenovat své manifesty na přítomnost privileged: true ještě předtím, než se dostanou do clusteru, máte z poloviny vyhráno. Když použijete nástroj jako Penetrify k nepřetržité simulaci útoků na vaše prostředí, už nehádáte, zda vaše síťové politiky fungují – máte důkaz.

Pamatujte, že zabezpečení není cíl; je to proces snižování rizika. Nikdy nebudete mít "100% zabezpečený" cluster, ale opravou těchto běžných chybných konfigurací to útočníkovi natolik ztížíte a prodražíte, že se pravděpodobně přesune na snazší cíl.

Jste připraveni přestat hádat o zabezpečení vašeho clusteru? Nečekejte na narušení, abyste zjistili, že vaše RBAC je příliš otevřené nebo že vaše síťové politiky mají mezery. Navštivte Penetrify a zjistěte, jak vám automatizované bezpečnostní testování na vyžádání může pomoci najít a opravit zranitelnosti v reálném čase a udržet vaši cloud-native infrastrukturu skutečně bezpečnou.

Zpět na blog