Späť na blog
29. apríla 2026

Ako opraviť bežné nesprávne konfigurácie v Kubernetes klastroch

Pravdepodobne ste už počuli vtip, že Kubernetes je v podstate obrovská kopa YAML súborov držaná pohromade nádejou a niekoľkými veľmi vystresovanými SREs. Hoci je to trochu prehnané, vystihuje to základnú pravdu: Kubernetes je neuveriteľne komplexný. Je to výkonný orchestrátor, ale táto sila prichádza so strmou krivkou učenia. Keď sa pohybujete rýchlo – nasadzujete aktualizácie viackrát denne, škálujete pody naprieč regiónmi a spravujete service meshe – je takmer nevyhnutné, že niečo bude nesprávne nakonfigurované.

Problém je v tom, že v cloud-native prostredí môže malý preklep v manifeste alebo „dočasná“ úprava povolení otvoriť obrovskú dieru vo vašej bezpečnosti. Všetci sme to zažili. Chceli ste len, aby sa pod spustil, a tak ste mu udelili cluster-admin oprávnenia „len na sekundu“, aby ste vyriešili problém s pripojením. Potom ste na to zabudli. O šesť mesiacov neskôr tento pod stále beží a je teraz zlatou vstupenkou pre každého útočníka, ktorému sa podarí získať shell vo vašom kontajneri.

Oprava bežných nesprávnych konfigurácií v Kubernetes klastroch nie je len o spustení bezpečnostného skenera a odškrtávaní políčok. Je to o pochopení „prečo“ za rizikami. Ak nerozumiete, ako môže privilegovaný kontajner viesť k úplnému prelomeniu uzla, budete stále robiť tie isté chyby zakaždým, keď napíšete nový deployment súbor.

V tejto príručke si prejdeme najčastejšie chyby, ktoré vidíme v praxi, a čo je dôležitejšie, presne ako ich opraviť. Pozrieme sa na všetko od nočných môr Role-Based Access Control (RBAC) až po nebezpečenstvá predvoleného menného priestoru. Na konci by ste mali mať jasný plán na posilnenie vášho klastra bez narušenia vašich aplikácií.

Nebezpečenstvo príliš privilegovaných servisných účtov (RBAC)

Role-Based Access Control (RBAC) je srdcom bezpečnosti Kubernetes. Určuje, kto môže robiť čo a kde. Avšak, RBAC je miesto, kde väčšina ľudí začína skracovať cestu. Keď vývojár povie: „Nemôžem prinútiť svoju CI/CD pipeline, aby nasadila aplikáciu,“ najjednoduchším riešením je často udeliť servisnému účtu cluster-admin oprávnenia.

Funguje to. Pipeline sa zazelená. Všetci sú šťastní. Ale práve ste vytvorili obrovskú zraniteľnosť. Ak unikne váš CI/CD tajný kľúč, útočník nemá prístup len k jednej aplikácii; má kľúče k celému vášmu kráľovstvu.

Pasca „Cluster-Admin“

Rola cluster-admin je vstavaná ClusterRole, ktorá poskytuje neobmedzený prístup ku každému zdroju v klastri. Používanie tohto pre servisné účty na úrovni aplikácií je kardinálnym hriechom bezpečnosti K8s.

Riešenie: Princíp najmenších privilégií (PoLP) Namiesto používania širokých rolí musíte definovať špecifické roly, ktoré povoľujú len presne požadované akcie.

Napríklad, ak pod potrebuje len čítať ConfigMaps vo svojom vlastnom mennom priestore, aby sa spustil, nedávajte mu ClusterRole. Dajte mu Role (ktorá je viazaná na menný priestor) len s príkazmi get a list pre configmaps.

Príklad sprísnenej roly:

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

Vyhýbanie sa predvolenému servisnému účtu

Predvolene má každý menný priestor servisný účet s názvom default. Ak pre pod neurčíte servisný účet, Kubernetes mu pridelí tento. Historicky mal predvolený servisný účet široké oprávnenia. Hoci moderné verzie sú lepšie, mnoho starších klastrov má stále účet default viazaný na príliš povolené roly.

Riešenie: Explicitné servisné účty Nikdy sa nespoliehajte na predvolené nastavenia. Vytvorte vyhradený servisný účet pre každú jednotlivú aplikáciu.

  1. Vytvorte ServiceAccount.
  2. Vytvorte Role s minimálnymi potrebnými oprávneniami.
  3. Vytvorte RoleBinding na prepojenie týchto dvoch.
  4. Explicitne nastavte serviceAccountName vo vašej špecifikácii Podu.

Ak vaša aplikácia vôbec nepotrebuje komunikovať s Kubernetes API (čo platí pre väčšinu webových aplikácií), posuňte sa o krok ďalej. Nastavte automountServiceAccountToken: false vo vašej špecifikácii podu. Tým sa zabráni pripojeniu API tokenu do podu, čo znamená, že aj keď sa útočník dostane dnu, nebude mať žiadny token na použitie pre laterálny pohyb v rámci klastra.

Posilnenie bezpečnostného kontextu Podu

Keď beží kontajner, nebeží len „v“ klastri; beží ako proces na uzle Linuxu. Ak tento proces beží ako používateľ root a existuje zraniteľnosť v runtime kontajnera alebo v jadre, útočník môže potenciálne „uniknúť“ z kontajnera a získať root prístup k hostiteľskému stroju. Toto je známe ako únik z kontajnera.

Problém s „Privileged: True“

Často uvidíte privileged: true v YAML súboroch. To v podstate hovorí Kubernetes, aby kontajneru udelil takmer všetky možnosti hostiteľského stroja. Pre štandardné aplikácie je to zriedka potrebné. Zvyčajne je to potrebné len pre špecializované systémové nástroje (ako sú CNI pluginy alebo ovládače úložiska).

Riešenie: Prestaňte používať privilegovaný režim Ak zistíte, že potrebujete privileged: true, spýtajte sa prečo. Potrebujete len zmeniť nastavenie siete? Potrebujete pripojiť konkrétne zariadenie?

Namiesto plného privilegovaného režimu použite capabilities. Linuxové `capabilities` vám umožňujú rozdeliť „root“ oprávnenia na menšie časti. Napríklad, ak potrebujete len upraviť sieťové rozhrania, použite CAP_NET_ADMIN namiesto udelenia plného root prístupu podu.

Spúšťanie ako Root

Mnoho Docker obrazov je štandardne vytvorených tak, aby bežali ako root. Ak ich nasadíte tak, ako sú, váš proces beží s UID 0. Toto predstavuje obrovské riziko.

Riešenie: Použite používateľa bez root oprávnení Mali by ste vynútiť spúšťanie bez root oprávnení ako v Dockerfile, tak aj v Kubernetes securityContext.

Vo vašom deployment YAML pridajte sekciu securityContext:

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

runAsNonRoot: true hovorí Kubernetes, aby skontroloval, či sa obraz pokúša spustiť ako root, a ak áno, zlyhal pri štarte. To núti váš tím vytvárať obrazy s vyhradeným používateľom (napr. USER 1000 v Dockerfile).

Súborové systémy root iba na čítanie

Väčšina aplikácií v skutočnosti nepotrebuje zapisovať do svojho vlastného root súborového systému. Zapisujú do logov (ktoré by mali ísť na stdout/stderr) alebo do pripojených zväzkov. Ak útočník získa prístup ku kontajneru, prvá vec, ktorú zvyčajne urobí, je stiahnutie sady nástrojov alebo skriptu na lokálny disk. Ak je súborový systém iba na čítanie, tento vektor útoku je zablokovaný.

Riešenie: Nastavte readOnlyRootFilesystem na true

securityContext:
  readOnlyRootFilesystem: true

Ak vaša aplikácia potrebuje zapisovať do dočasných súborov, nevypínajte súborový systém iba na čítanie. Namiesto toho pripojte zväzok emptyDir do konkrétnej cesty, kam aplikácia potrebuje zapisovať (napríklad /tmp).

Správa vašej útočnej plochy: Sieťové politiky

V predvolenom nastavení má Kubernetes "plochú" sieť. To znamená, že akýkoľvek pod v akomkoľvek mennom priestore môže komunikovať s akýmkoľvek iným podom v akomkoľvek inom mennom priestore. Hoci je to skvelé pre konektivitu, pre bezpečnosť je to nočná mora. Ak je váš frontendový webový server kompromitovaný, útočník môže voľne skenovať vašu internú sieť a nájsť vašu databázu, vašu cache a vaše interné administrátorské nástroje.

Nedostatok segmentácie

Predstavte si dom, kde medzi miestnosťami nie sú žiadne dvere – len jeden veľký otvorený priestor. Ak sa vlámač dostane cez predné okno, má okamžitý prístup do spálne, kuchyne a k trezoru. Presne tak funguje predvolený K8s klaster.

Riešenie: Implementujte politiku predvoleného odmietnutia Najbezpečnejší spôsob riadenia sieťovej prevádzky je začať blokovaním všetkého a potom explicitne povoliť len to, čo je nevyhnutné. Toto je prístup "Zero Trust".

Najprv vytvorte politiku, ktorá zahadzuje všetku prichádzajúcu a odchádzajúcu prevádzku pre menný priestor:

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

Keď je všetko zablokované, vytvoríte špecifické pravidlá "povolenia". Napríklad, ak váš pod frontend potrebuje komunikovať s vaším podom backend na porte 8080, napíšete politiku, ktorá špecificky povoľuje prevádzku z označenia frontend na označenie backend na tomto porte.

Kontrola odchádzajúcej prevádzky

Väčšina ľudí sa zameriava na to, kto sa môže dostať do ich klastra, ale zabúdajú na to, čo ide von. Ak je pod kompromitovaný, útočník sa pokúsi "zavolať domov" na server command-and-control (C2), aby prijal inštrukcie alebo exfiltroval dáta.

Riešenie: Obmedzte odchádzajúcu prevádzku Pokiaľ váš pod nepotrebuje komunikovať s verejným internetom (čo je pre backendovú službu zriedkavé), zablokujte všetku odchádzajúcu prevádzku. Ak potrebuje prístup na internet (napríklad na volanie API tretej strany ako Stripe alebo Twilio), použite service mesh ako Istio alebo Linkerd, alebo použite Egress Gateway na povolenie špecifických externých domén.

Pasca "bodu v čase" a nepretržité testovanie

Jedna z najväčších nesprávnych konfigurácií nie je riadok kódu – je to proces. Mnoho spoločností vykonáva "bezpečnostný audit" raz za štvrťrok. Najmú si firmu, firma nájde desať nesprávnych konfigurácií, tím ich opraví a všetci si vydýchnu.

Ale prostredia Kubernetes sú dynamické. Zajtra môžete zmeniť ConfigMap, aktualizovať Helm chart alebo pridať nový sidecar kontajner. Ten "čistý" audit z minulého mesiaca je teraz irelevantný. Toto nazývame "bod v čase" bezpečnosť, a v cloud-native svete je to nebezpečné.

Tu je potrebný posun smerom k Continuous Threat Exposure Management (CTEM). Nemôžete len skenovať zraniteľnosti; musíte simulovať, ako sa útočník skutočne pohybuje vo vašom klastri.

Ak máte pod s príliš permisívnou RBAC rolou a nesprávne nakonfigurovanou Network Policy, jednoduchý sken zraniteľností ich môže označiť ako dve samostatné "stredné" riziká. Ale v skutočnosti spolu vytvárajú "kritickú" cestu: útočník zneužije webovú zraniteľnosť, použije RBAC rolu na zoznam tajomstiev, nájde heslo k databáze a použije otvorenú sieť na vyhodenie vašich dát.

Nástroje ako Penetrify pomáhajú preklenúť túto medzeru. Namiesto statickej správy, ktorá len zbiera prach, Penetrify poskytuje bezpečnostné testovanie na požiadanie, ktoré sa škáluje s vaším cloudovým prostredím. Pomáha vám identifikovať tieto „reťazce“ nesprávnych konfigurácií – spôsob, akým sa malá chyba RBAC kombinuje so sieťovou medzerou – skôr, než to urobí škodlivý aktér. Prechodom na model „Penetration Testing as a Service“ (PTaaS) prestanete hádať, či je váš klaster bezpečný, a začnete to vedieť.

Zabezpečenie API servera a riadiacej roviny

API server je mozgom vášho klastra. Všetko – od príkazov kubectl po internú logiku kontroléra – prechádza cez neho. Ak je API server vystavený alebo nesprávne nakonfigurovaný, celý váš klaster je kompromitovaný.

Verejne prístupné API servery

V zhone spustiť klaster niektoré tímy nechávajú API server otvorený celému internetu. Hoci je chránený autentifikáciou, vystavenie koncového bodu umožňuje útočníkom pokúšať sa o útoky hrubou silou, zneužívať Zero Day zraniteľnosti v samotnom API serveri alebo vykonávať útoky typu odmietnutie služby.

Riešenie: Používajte súkromné koncové body a autorizované siete Ak používate spravovanú službu ako EKS, GKE alebo AKS, povoľte možnosť „Súkromný klaster“. To zaisťuje, že API server je prístupný iba z vášho VPC alebo prostredníctvom VPN/Bastion hostiteľa. Ak ho musíte ponechať verejný, použite „Autorizované siete“ (whitelisting IP adries) na obmedzenie prístupu iba na IP adresu vašej kancelárie alebo IP adresy vašich CI/CD runnerov.

Anonymná autentifikácia

Niektoré staršie klastre alebo vlastné inštalácie môžu mať povolenú anonymnú autentifikáciu. To umožňuje, aby sa požiadavky na API server, ktoré nie sú autentifikované, spracovávali ako špeciálny používateľ system:anonymous. V závislosti od vašich nastavení RBAC môže mať tento používateľ náhodne povolenia na prezeranie podov alebo uzlov.

Riešenie: Zakážte anonymnú autentifikáciu Uistite sa, že príznak --anonymous-auth=false je nastavený na vašom kube-apiserveri. Ak ho z nejakého dôvodu nemôžete zakázať, uistite sa, že používateľ system:anonymous nie je viazaný na žiadne roly, ktoré poskytujú informácie o vašom klastri.

Zabezpečenie Etcd

Etcd je databáza, kde Kubernetes ukladá všetky svoje stavy. Ak útočník získa prístup k etcd, má všetko: každý tajný kľúč, každú konfiguráciu a schopnosť modifikovať stav klastra bez prechodu cez API server.

Riešenie: Šifrujte a izolujte etcd

  1. Šifrovanie v pokoji: Povoľte šifrovanie tajných kľúčov v etcd, aby v prípade krádeže alebo prístupu k disku boli tajné kľúče bezcenné.
  2. Vzájomné TLS (mTLS): Zabezpečte, aby API server a etcd komunikovali pomocou certifikátov. Nikto by nemal byť schopný komunikovať s etcd bez platného klientskeho certifikátu.
  3. Sieťová izolácia: etcd by malo byť na úplne oddelenej sieti alebo chránené prísnymi pravidlami firewallu, aby k nemu mal prístup iba API server.

Správa tajných kľúčov bez „Secret“

Názov Secret v Kubernetes je tak trochu klamstvo. V predvolenom nastavení sú tajné kľúče Kubernetes iba kódované v base64, nie šifrované. Ktokoľvek s prístupom k API alebo zálohe etcd môže dekódovať vaše databázové heslo približne za dve sekundy pomocou jednoduchého terminálového príkazu: echo "base64-string" | base64 --decode.

Ukladanie tajných kľúčov v Git (Najväčší hriech)

Stáva sa to častejšie, než si ľudia pripúšťajú. Vývojár vloží súbor secret.yaml do Git repozitára „len na pár minút“, aby pomohol kolegovi, a potom ho zabudne odstrániť. Teraz toto heslo žije v histórii Gitu navždy.

Riešenie: Externá správa tajných kľúčov Prestaňte používať natívne tajné kľúče K8s pre citlivé dáta. Namiesto toho použite vyhradeného správcu tajných kľúčov.

  • HashiCorp Vault: Priemyselný štandard. Poskytuje dynamické tajomstvá a prísnu kontrolu prístupu.
  • AWS Secrets Manager / Azure Key Vault / GCP Secret Manager: Skvelé, ak ste už viazaní na konkrétneho poskytovateľa cloudu.

Na integráciu týchto nástrojov s Kubernetes použite nástroje ako External Secrets Operator (ESO) alebo Secrets Store CSI Driver. Tieto nástroje načítajú tajomstvo z externého úložiska a vložia ho do podu ako zväzok (volume) alebo dočasné tajomstvo K8s, čím sa zabezpečí, že skutočný "zdroj pravdy" nikdy nebude uložený vo vašich súboroch YAML alebo v Gite.

Rotácia tajomstiev

Väčšina tímov nastaví heslo a nechá ho tri roky. Ak toto heslo unikne, útočník má trvalé zadné vrátka.

Riešenie: Automatizovaná rotácia Ak používate externého správcu ako Vault, môžete implementovať automatickú rotáciu. Správca tajomstiev aktualizuje heslo v databáze a potom aktualizuje hodnotu v Kubernetes. Pretože aplikácia číta tajomstvo zo zväzku (volume) alebo prostredníctvom API, prevezme nové heslo bez potreby úplného opätovného nasadenia (redeploy).

Limity zdrojov a problém "hlučného suseda"

Hoci nejde o "bezpečnostnú" chybnú konfiguráciu v tradičnom zmysle, nenastavenie limitov zdrojov predstavuje riziko pre stabilitu a dostupnosť. V Kubernetes, ak sa jeden pod vymkne kontrole a začne spotrebúvať všetok CPU alebo RAM na uzle, môže to obmedziť iné pody—vrátane kritických systémových komponentov—čo vedie k zlyhaniu uzla. Ide v podstate o samo-spôsobený Denial of Service (DoS).

Nebezpečenstvo "neobmedzených" podov

Ak nedefinujete resources.limits, pod môže použiť toľko zdrojov uzla, koľko chce. Ak máte únik pamäte v jednej z vašich aplikácií, pomaly spotrebuje všetku RAM na uzle, kým Linux OOM (Out of Memory) killer nezačne zabíjať procesy. Problém? OOM killer môže najprv zabiť váš najdôležitejší pod.

Riešenie: Nastavte požiadavky (Requests) a limity (Limits) Každý kontajner by mal mať request (čo potrebuje na spustenie) a limit (maximum, ktoré smie použiť).

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"
  • Požiadavky (Requests): Používa ich plánovač na nájdenie uzla s dostatočným priestorom.
  • Limity (Limits): Vynucuje ich runtime kontajnera, aby zabránil podu zaberať celý uzol.

Spracovanie obmedzovania CPU (CPU Throttling)

Buďte opatrní s limitmi CPU. Na rozdiel od pamäte (kde dosiahnutie limitu zabije pod), dosiahnutie limitu CPU pod iba "škrtí" (throttles). Vaša aplikácia sa spomalí, ale nezlyhá. Ak spozorujete vysokú latenciu vo vašich aplikáciách, skontrolujte metriky Prometheus pre obmedzovanie CPU (CPU throttling). Možno budete musieť zvýšiť svoje limity alebo optimalizovať kód.

Bezpečnosť obrazov (Image Security) a riziká dodávateľského reťazca

Váš klaster je taký bezpečný, ako sú bezpečné obrazy, ktoré v ňom spúšťate. Ak sťahujete my-app:latest z verejného registra, v podstate spúšťate kód napísaný cudzincom na vašej produkčnej infraštruktúre.

Používanie tagu :latest

Používanie :latest je recept na katastrofu. Nemáte tušenie, ktorá verzia kódu sa skutočne spúšťa. Keď sa pod reštartuje, môže stiahnuť novú verziu obrazu, ktorá obsahuje zásadnú zmenu alebo, čo je horšie, škodlivý náklad.

Riešenie: Používajte nemenné tagy alebo digest-y Vždy používajte špecifický tag verzie (napr. my-app:v1.2.3) alebo, pre maximálnu bezpečnosť, SHA256 digest obrazu. To zaisťuje, že presne tie isté bajty sú nasadené vždy.

Spúšťanie obrazov z nedôveryhodných registrov

Verejné registre sú plné "typo-squatted" obrazov—obrazov, ktoré vyzerajú ako populárne, ale obsahujú malvér.

Riešenie: Súkromný register a skenovanie obrazov

  1. Používajte súkromný register: Sťahujte verejné obrazy, skenujte ich a potom ich nahrávajte do vlastného súkromného registra (ako ECR, ACR alebo Harbor).
  2. Automatizované skenovanie: Používajte skener ako Trivy alebo Clair na kontrolu známych CVE (Common Vulnerabilities and Exposures) vo vašich obrazoch.
  3. Admission controllery: Používajte nástroj ako Kyverno alebo OPA (Open Policy Agent), aby ste zabránili nasadeniu akéhokoľvek obrazu, ak nebol skenovaný alebo ak obsahuje "kritické" zraniteľnosti.

Komplexný kontrolný zoznam pre posilnenie bezpečnosti Kubernetes

Aby to bolo prakticky využiteľné, tu je súhrnný kontrolný zoznam, ktorý môžete použiť počas vášho ďalšieho sprintu alebo bezpečnostnej previerky.

RBAC a prístup

  • Žiadne servisné účty s oprávnením cluster-admin (pokiaľ to nie je absolútne nevyhnutné).
  • Žiadne aplikácie nepoužívajúce default servisný účet.
  • automountServiceAccountToken: false nastavené pre pody, ktoré nepotrebujú prístup k API.
  • API Server nie je otvorený pre verejný internet.
  • Anonymná autentifikácia je na API serveri zakázaná.

Bezpečnosť podov

  • privileged: true je zakázané pre aplikačné pody.
  • runAsNonRoot: true a runAsUser sú definované pre všetky kontajnery.
  • readOnlyRootFilesystem: true je povolené všade, kde je to možné.
  • limits a requests pre CPU a pamäť sú nastavené pre každý kontajner.

Sieťová bezpečnosť

  • default-deny-all NetworkPolicy je zavedená pre každý namespace.
  • Explicitné pravidlá "Allow" sa používajú pre nevyhnutnú komunikáciu medzi službami.
  • Odchádzajúca prevádzka je obmedzená na známe, požadované koncové body.

Dáta a tajomstvá

  • Žiadne tajomstvá uložené v Git repozitároch.
  • Tajomstvá sú spravované prostredníctvom externého trezoru (Vault, AWS SM atď.).
  • Tajomstvá sú šifrované v kľude v etcd.
  • etcd je izolované a vyžaduje mTLS pre komunikáciu.

Dodávateľský reťazec

  • Obrazy sa sťahujú zo súkromného, dôveryhodného registra.
  • Žiadne obrazy nepoužívajú tag :latest vo výrobe.
  • Všetky obrazy sú skenované na CVE pred nasadením.
  • Admission controller blokuje nevyhovujúce obrazy.

Bežné scenáre nesprávnej konfigurácie: Pred a Po

Aby ste získali jasnejší obraz o tom, ako tieto opravy vyzerajú v praxi, pozrime sa na niekoľko scenárov "Pred a Po".

Scenár 1: "Lenivé" nasadenie

Predtým: Vývojár nasadí jednoduché Node.js API. Používa predvolený servisný účet, beží ako root, nemá žiadne limity zdrojov a žiadne sieťové politiky.

  • Riziko: Zraniteľnosť v balíku Node umožní útočníkovi získať shell. Keďže je root a má predvolený token, môže preskúmať internú sieť, nájsť databázu a potenciálne eskalovať oprávnenia na uzol.

Potom:

  • Použite vlastný ServiceAccount bez API oprávnení.
  • Nastavte runAsNonRoot: true.
  • Definujte limity cpu a memory.
  • Aplikujte NetworkPolicy, ktorá povoľuje prevádzku len z Ingress Controlleru.
  • Výsledok: Aj keď útočník získa shell, je používateľom s nízkymi oprávneniami, nemôže komunikovať s inými podmi a nemôže zhodiť uzol spotrebovaním celej RAM.

Scenár 2: Únik "tajomstva"

Predtým:
Tím ukladá heslo k databáze v Kubernetes Secret vytvorenom z lokálneho YAML súboru. YAML súbor bol omylom commitnutý do feature branchu.

  • Riziko: Ktokoľvek s prístupom na čítanie k histórii Gitu má teraz heslo k produkčnej databáze.

Potom:

  • Presuňte heslo do AWS Secrets Manager.
  • Nainštalujte External Secrets Operator.
  • K8s secret je teraz "tieňom" AWS secretu a nikdy nie je uložený v Gite.
  • Výsledok: Secret je centralizovaný, automaticky rotovaný a nikdy sa nedotkne lokálneho disku vývojára v nešifrovanej podobe.

Často kladené otázky (FAQ)

1. Nespôsobí nastavenie limitov zdrojov pád mojich podov?

Áno, ak nastavíte limit pamäte príliš nízko, váš pod bude OOMKilled. To je v skutočnosti dobrá vec – je lepšie, aby jeden pod spadol a reštartoval sa, než aby jeden pod zhodil celý váš fyzický uzol. Trik spočíva v monitorovaní skutočného využitia vašej aplikácie pomocou nástrojov ako Prometheus a Grafana a následnom nastavení limitov mierne nad špičkové využitie.

2. Je skutočne potrebné použiť Service Mesh pre sieťovú bezpečnosť?

Pre malé klastre môže byť Service Mesh (ako Istio) prehnaný. Štandardné Kubernetes NetworkPolicies sú zvyčajne dostatočné na to, aby vás dostali na 80 % cesty. Ak však potrebujete pokročilé funkcie, ako je vzájomné TLS (mTLS) medzi všetkými službami alebo komplexné rozdelenie prevádzky, service mesh je správny krok.

3. Ako nájdem všetky svoje aktuálne nesprávne konfigurácie bez kontroly každého YAML súboru?

Robiť to manuálne je nemožné, akonáhle máte viac ako niekoľko aplikácií. Mali by ste použiť automatizované nástroje. Nástroje ako kube-bench (ktorý kontroluje podľa CIS benchmarkov) a kube-hunter sú skvelé na hľadanie dier. Pre nepretržitejší "pohľad útočníka" na váš klaster môže platforma ako Penetrify automaticky mapovať vašu útočnú plochu a nájsť cesty, ktorými by sa útočník skutočne vydal.

4. Funguje runAsNonRoot, ak bol image postavený ako root?

Ak nastavíte runAsNonRoot: true a metadáta image hovoria, že beží ako root (UID 0), Kubernetes odmietne spustiť pod. Musíte sa vrátiť k Dockerfile a pridať používateľa (napr. RUN useradd -u 1000 appuser && USER appuser).

5. Môžem aplikovať tieto bezpečnostné nastavenia na existujúci klaster bez výpadku?

Áno, ale robte to opatrne. Neaplikujte default-deny-all sieťovú politiku na celý váš produkčný namespace naraz, inak vypnete celú vašu stránku. Aplikujte politiky jednu službu po druhej. Podobne otestujte zmeny vášho securityContext v staging prostredí, aby ste sa uistili, že vaša aplikácia nepotrebuje špecifické root oprávnenie na zápis do priečinka.

Prechod od reaktívnej k proaktívnej bezpečnosti

Oprava nesprávnych konfigurácií je neustály boj. S pridávaním ďalších služieb, vývojárov a komplexnejších integrácií rastie "bezpečnostná plocha" vášho klastra. Ak sa spoliehate na manuálny kontrolný zoznam alebo audit raz ročne, v podstate hráte hru na krtka, kde má krtek raketomet.

Cieľom by malo byť prejsť z reaktívneho stavu – kde veci opravujete až potom, čo sú označené – do proaktívneho stavu. To znamená integrovať bezpečnosť do vášho CI/CD pipeline (DevSecOps) a používať nepretržité testovanie.

Automatizácia je jediný spôsob, ako držať krok s rýchlosťou Kubernetes. Keď dokážete automaticky skenovať svoje manifesty na prítomnosť privileged: true ešte predtým, ako sa dostanú do klastra, máte polovicu bitky vyhranú. Keď použijete nástroj ako Penetrify na nepretržitú simuláciu útokov na vaše prostredie, už nehádžete, či vaše sieťové politiky fungujú – máte dôkaz.

Pamätajte, bezpečnosť nie je cieľ; je to proces znižovania rizika. Nikdy nebudete mať "100% zabezpečený" klaster, ale opravou týchto bežných nesprávnych konfigurácií to útočníkovi tak sťažíte a predražíte, že sa pravdepodobne presunie na ľahší cieľ.

Ste pripravení prestať hádať o bezpečnosti vášho klastra? Nečakajte na narušenie, aby ste zistili, že vaše RBAC je príliš otvorené alebo že vaše sieťové politiky majú diery. Navštívte Penetrify a zistite, ako vám automatizované, on-demand bezpečnostné testovanie môže pomôcť nájsť a opraviť zraniteľnosti v reálnom čase, čím udržíte vašu cloud-native infraštruktúru skutočne bezpečnú.

Späť na blog