Úvod do sieťových zásad Kubernetes pre profesionálov v oblasti bezpečnosti

Poznámka. preklad.: Autor článku, Reuven Harrison, má viac ako 20 rokov skúseností s vývojom softvéru a dnes je CTO a spoluzakladateľom spoločnosti Tufin, ktorá vytvára riešenia na správu bezpečnostnej politiky. Aj keď považuje sieťové politiky Kubernetes za pomerne silný nástroj na segmentáciu siete v klastri, zároveň sa domnieva, že ich implementácia v praxi nie je taká jednoduchá. Tento materiál (celkom objemný) je určený na zlepšenie informovanosti odborníkov o tejto problematike a na pomoc pri vytváraní potrebných konfigurácií.

Dnes si mnoho spoločností čoraz viac vyberá Kubernetes na spustenie svojich aplikácií. Záujem o tento softvér je taký vysoký, že niektorí nazývajú Kubernetes „nový operačný systém pre dátové centrum“. Postupne sa Kubernetes (alebo k8s) začína vnímať ako kritická súčasť podnikania, ktorá si vyžaduje organizáciu vyspelých obchodných procesov vrátane zabezpečenia siete.

Pre bezpečnostných profesionálov, ktorí sú zmätení prácou s Kubernetes, môže byť skutočným odhalením predvolená politika platformy: povoliť všetko.

Táto príručka vám pomôže pochopiť vnútornú štruktúru sieťových zásad; pochopiť, ako sa líšia od pravidiel pre bežné brány firewall. Pokryje aj niektoré úskalia a poskytne odporúčania, ktoré pomôžu zabezpečiť aplikácie na Kubernetes.

Sieťové pravidlá Kubernetes

Mechanizmus sieťovej politiky Kubernetes vám umožňuje riadiť interakciu aplikácií nasadených na platforme na sieťovej vrstve (tretia v modeli OSI). Sieťovým politikám chýbajú niektoré pokročilé funkcie moderných brán firewall, ako je vynucovanie OSI Layer 7 a detekcia hrozieb, ale poskytujú základnú úroveň zabezpečenia siete, ktorá je dobrým východiskovým bodom.

Sieťové politiky riadia komunikáciu medzi modulmi

Pracovné zaťaženia v Kubernetes sú rozdelené medzi moduly, ktoré pozostávajú z jedného alebo viacerých kontajnerov nasadených spoločne. Kubernetes priradí každému modulu IP adresu, ktorá je dostupná z iných modulov. Sieťové pravidlá Kubernetes nastavujú prístupové práva pre skupiny modulov rovnakým spôsobom, akým sa bezpečnostné skupiny v cloude používajú na riadenie prístupu k inštanciám virtuálnych počítačov.

Definovanie sieťových politík

Rovnako ako ostatné zdroje Kubernetes, aj sieťové politiky sú špecifikované v YAML. V nižšie uvedenom príklade aplikácia balance prístup k postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(Poznámka. preklad.: táto snímka obrazovky, rovnako ako všetky nasledujúce podobné, nebola vytvorená pomocou natívnych nástrojov Kubernetes, ale pomocou nástroja Tufin Orca, ktorý vyvinula spoločnosť autora pôvodného článku a ktorý je uvedený na konci materiálu.)

Na definovanie vlastnej sieťovej politiky budete potrebovať základné znalosti YAML. Tento jazyk je založený na odsadení (určené medzerami a nie tabulátormi). Odsadený prvok patrí najbližšiemu odsadenému prvku nad ním. Nový prvok zoznamu začína spojovníkom, všetky ostatné prvky majú tvar kľúč-hodnota.

Po opísaní politiky v YAML použite kubectlna jeho vytvorenie v klastri:

kubectl create -f policy.yaml

Špecifikácia sieťovej politiky

Špecifikácia sieťovej politiky Kubernetes obsahuje štyri prvky:

1. podSelector: definuje moduly ovplyvnené touto politikou (ciele) - povinné;
2. policyTypes: označuje, aké typy politík sú v tomto zahrnuté: vstup a/alebo výstup - voliteľné, ale odporúčam to vo všetkých prípadoch výslovne špecifikovať;
3. ingress: definuje povolené prichádzajúce návštevnosť cieľových modulov je voliteľná;
4. egress: definuje povolené vychádzajúce návštevnosť z cieľových modulov je voliteľná.

Príklad prevzatý z webovej stránky Kubernetes (nahradil som role na app), ukazuje, ako sa používajú všetky štyri prvky:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: db
  policyTypes:    # <<<
  - Ingress
  - Egress
  ingress:        # <<<
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:         # <<<
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Upozorňujeme, že nemusia byť zahrnuté všetky štyri prvky. Je to len povinné podSelector, ďalšie parametre je možné použiť podľa želania.

Ak vynecháte policyTypesbudú pravidlá interpretované takto:

• Štandardne sa predpokladá, že definuje vstupnú stranu. Ak to politika výslovne neuvádza, systém bude predpokladať, že všetka premávka je zakázaná.
• Správanie na výstupnej strane bude určené prítomnosťou alebo absenciou zodpovedajúceho výstupného parametra.

Aby ste sa vyhli chybám, odporúčam vždy to daj jasne najavo policyTypes.

Podľa vyššie uvedenej logiky, ak parametre ingress a / alebo egress vynechané, politika odmietne všetku premávku (pozrite „Pravidlo odstraňovania“ nižšie).

Predvolené pravidlo je Povoliť

Ak nie sú definované žiadne politiky, Kubernetes predvolene povolí všetku komunikáciu. Všetky moduly si môžu medzi sebou voľne vymieňať informácie. Z hľadiska bezpečnosti sa to môže zdať neintuitívne, ale nezabudnite, že Kubernetes pôvodne navrhli vývojári, aby umožnili interoperabilitu aplikácií. Sieťové pravidlá boli pridané neskôr.

Menné priestory

Menné priestory sú mechanizmus spolupráce Kubernetes. Sú navrhnuté tak, aby od seba izolovali logické prostredia, pričom komunikácia medzi priestormi je štandardne povolená.

Ako väčšina komponentov Kubernetes, aj sieťové politiky žijú v špecifickom mennom priestore. V bloku metadata môžete určiť, do ktorého priestoru politika patrí:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

Ak menný priestor nie je explicitne špecifikovaný v metaúdajoch, systém použije menný priestor špecifikovaný v kubectl (štandardne namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

odporúčam explicitne špecifikujte menný priestor, pokiaľ nepíšete politiku, ktorá sa zameriava na viacero menných priestorov naraz.

Primárne prvok podSelector v politike vyberie moduly z menného priestoru, do ktorého politika patrí (je zakázaný prístup k modulom z iného menného priestoru).

Podobne aj podSelectors vo vstupných a výstupných blokoch môžete vybrať moduly iba zo svojho vlastného menného priestoru, pokiaľ ich samozrejme neskombinujete s namespaceSelector (o tom sa bude diskutovať v časti „Filtrovanie podľa menných priestorov a modulov“).

Pravidlá pomenovania pravidiel

Názvy pravidiel sú jedinečné v rámci rovnakého menného priestoru. V rovnakom priestore nemôžu byť dve politiky s rovnakým názvom, ale v rôznych priestoroch môžu byť politiky s rovnakým názvom. Je to užitočné, keď chcete znova použiť rovnakú politiku vo viacerých priestoroch.

Obzvlášť sa mi páči jeden zo spôsobov pomenovania. Pozostáva z kombinácie názvu menného priestoru s cieľovými modulmi. Napríklad:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Štítky

K objektom Kubernetes, ako sú moduly a priestory názvov, môžete pripojiť vlastné štítky. Štítky (etikety - tagy) sú ekvivalentom tagov v cloude. Sieťové pravidlá Kubernetes používajú na výber štítky strukyna ktoré sa vzťahujú:

podSelector:
  matchLabels:
    role: db

… alebo menné priestoryna ktoré sa vzťahujú. Tento príklad vyberie všetky pody v priestoroch názvov so zodpovedajúcimi menovkami:

namespaceSelector:
  matchLabels:
    project: myproject

Jedno upozornenie: pri používaní namespaceSelector uistite sa, že priestory názvov, ktoré vyberiete, obsahujú správny štítok. Uvedomte si, že vstavané menné priestory ako napr default и kube-system, štandardne neobsahujú menovky.

Do priestoru môžete pridať štítok takto:

kubectl label namespace default namespace=default

Zároveň menný priestor v sekcii metadata by mal odkazovať na skutočný názov priestoru, nie na štítok:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

Zdroj a cieľ

Politiky brány firewall pozostávajú z pravidiel so zdrojmi a cieľmi. Sieťové politiky Kubernetes sú definované pre cieľ – skupinu modulov, na ktoré sa vzťahujú – a potom sa nastavujú pravidlá pre vstupnú a/alebo výstupnú prevádzku. V našom príklade budú cieľom politiky všetky moduly v mennom priestore default so štítkom s kľúčom app a zmysel db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Pododdiel ingress v tejto politike otvára prichádzajúcu návštevnosť do cieľových modulov. Inými slovami, vstup je zdroj a cieľ je zodpovedajúci cieľ. Rovnako aj výstup je cieľom a cieľ je jeho zdrojom.

To je ekvivalentné dvom pravidlám brány firewall: Ingress → Target; Cieľ → Výstup.

Egress a DNS (dôležité!)

Obmedzením odchádzajúcej premávky venujte zvláštnu pozornosť DNS - Kubernetes používa túto službu na mapovanie služieb na IP adresy. Napríklad nasledujúca zásada nebude fungovať, pretože ste aplikáciu nepovolili balance prístup k DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

Môžete to opraviť otvorením prístupu k službe DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

Posledný prvok to je prázdny, a preto nepriamo selektuje všetky pody vo všetkých menných priestoroch, dovoľovať balance odosielať dotazy DNS do príslušnej služby Kubernetes (zvyčajne beží v priestore kube-system).

Tento prístup však funguje príliš povoľný a neistý, pretože umožňuje, aby dotazy DNS smerovali mimo klastra.

Vylepšiť ho môžete v troch po sebe nasledujúcich krokoch.

1. Povoliť iba dotazy DNS vnútri zhlukovať pridaním namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. Povoliť DNS dotazy len v rámci menného priestoru kube-system.

Ak to chcete urobiť, musíte do menného priestoru pridať štítok kube-system: kubectl label namespace kube-system namespace=kube-system - a zapíšte si to do politiky používania namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. Paranoidní ľudia môžu ísť ešte ďalej a obmedziť DNS dotazy na konkrétnu DNS službu v kube-system. Časť „Filtrovať podľa menných priestorov a modulov“ vám povie, ako to dosiahnuť.

Ďalšou možnosťou je vyriešiť DNS na úrovni menného priestoru. V tomto prípade ho nebude potrebné otvárať pre každú službu:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

Prázdne podSelector vyberie všetky moduly v mennom priestore.

Prvý zápas a poradie pravidiel

V konvenčných firewalloch je akcia (Povoliť alebo Zakázať) na paket určená prvým pravidlom, ktoré spĺňa. V Kubernetes na poradí politík nezáleží.

V predvolenom nastavení, keď nie sú nastavené žiadne pravidlá, je komunikácia medzi modulmi povolená a môžu si voľne vymieňať informácie. Keď začnete formulovať politiky, každý modul ovplyvnený aspoň jednou z nich sa izoluje podľa disjunkcie (logického OR) všetkých politík, ktoré ho vybrali. Moduly, ktoré nie sú ovplyvnené žiadnou politikou, zostávajú otvorené.

Toto správanie môžete zmeniť pomocou pravidla odstraňovania.

Pravidlo odstraňovania („Odmietnuť“)

Zásady brány firewall zvyčajne zakazujú akúkoľvek prevádzku, ktorá nie je výslovne povolená.

V Kubernetes nie je žiadna akcia odmietnutia, podobný efekt však možno dosiahnuť pomocou bežnej (povolenej) politiky výberom prázdnej skupiny zdrojových modulov (vstup):

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

Táto zásada vyberie všetky moduly v mennom priestore a ponechá vstup nedefinovaný, čím zakáže všetku prichádzajúcu návštevnosť.

Podobným spôsobom môžete obmedziť všetku odchádzajúce prenosy z priestoru názvov:

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

Upozorňujeme, že akékoľvek ďalšie pravidlá umožňujúce návštevnosť modulov v mennom priestore budú mať prednosť pred týmto pravidlom (podobne ako pridanie pravidla povolenia pred pravidlo odmietnutia v konfigurácii brány firewall).

Povoliť všetko (Any-Any-Any-Allow)

Ak chcete vytvoriť politiku Povoliť všetko, musíte vyššie uvedenú politiku odmietnutia doplniť prázdnym prvkom ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

Umožňuje prístup z všetky moduly vo všetkých priestoroch názvov (a všetky adresy IP) na ľubovoľný modul v priestore názvov default. Toto správanie je predvolene povolené, takže ho zvyčajne netreba ďalej definovať. Niekedy však možno budete musieť dočasne zakázať niektoré špecifické povolenia na diagnostiku problému.

Pravidlo je možné zúžiť tak, aby umožňovalo prístup iba pre špecifickú sadu strukov (app:balance) v priestore názvov default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

Nasledujúca politika povoľuje všetku vstupnú a výstupnú prevádzku vrátane prístupu k akejkoľvek IP mimo klastra:

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

Kombinácia viacerých politík

Politiky sú kombinované pomocou logického OR na troch úrovniach; Povolenia každého modulu sú nastavené v súlade so všetkými zásadami, ktoré ho ovplyvňujú:

1. Na poliach from и to Je možné definovať tri typy prvkov (všetky sú kombinované pomocou OR):

• namespaceSelector — vyberie celý menný priestor;
• podSelector — vyberá struky;
• ipBlock — vyberie podsieť.

Navyše počet prvkov (aj identických) v podsekciách from/to nie je obmedzený. Všetky budú spojené logickým ALEBO.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. Vo vnútri sekcie zásad ingress môže mať veľa prvkov from (spojené logickým OR). Podobne aj oddiel egress môže obsahovať veľa prvkov to (tiež kombinované disjunkciou):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. Rôzne politiky sú tiež kombinované s logickým OR

Pri ich kombinovaní však existuje jedno obmedzenie poukázal Chris Cooney: Kubernetes môže kombinovať iba politiky s rôznymi policyTypes (Ingress alebo Egress). Politiky definujúce vstup (alebo výstup) sa navzájom prepíšu.

Vzťah medzi mennými priestormi

Zdieľanie informácií medzi mennými priestormi je štandardne povolené. Toto je možné zmeniť použitím politiky odmietnutia, ktorá obmedzí odchádzajúcu a/alebo prichádzajúcu prevádzku do menného priestoru (pozrite „Pravidlo odstraňovania“ vyššie).

Keď zablokujete prístup k priestoru názvov (pozrite si „pravidlo odstraňovania“ vyššie), môžete urobiť výnimky zo zásady odmietnutia povolením pripojení z konkrétneho priestoru názvov pomocou namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

Výsledkom je, že všetky moduly v mennom priestore default bude mať prístup k modulom postgres v mennom priestore database. Ale čo ak chcete otvoriť prístup k postgres iba konkrétne pody v mennom priestore default?

Filtrujte podľa menných priestorov a podov

Kubernetes verzie 1.11 a vyššej umožňuje kombinovať operátory namespaceSelector и podSelector pomocou logického AND. Vyzerá to takto:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Prečo sa to interpretuje ako AND namiesto obvyklého ALEBO?

Vezmite prosím na vedomie, že podSelector nezačína spojovníkom. V YAML to znamená podSelector a stojaci pred ním namespaceSelector odkazovať na rovnaký prvok zoznamu. Preto sú kombinované s logickým AND.

Pred pridanie spojovníka podSelector bude mať za následok vznik nového prvku zoznamu, ktorý sa skombinuje s predchádzajúcim namespaceSelector pomocou logického OR.

Ak chcete vybrať pody s konkrétnym štítkom vo všetkých menných priestoroch, zadajte prázdne namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Viaceré štítky sa spojili s I

Pravidlá pre firewall s viacerými objektmi (hostiteľmi, sieťami, skupinami) sú kombinované pomocou logického OR. Nasledujúce pravidlo bude fungovať, ak sa zdroj paketu zhoduje Host_1 OR Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

Naopak, v Kubernetes rôzne štítky v podSelector alebo namespaceSelector sú kombinované s logickým AND. Napríklad nasledujúce pravidlo vyberie moduly, ktoré majú oba štítky, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Rovnaká logika platí pre všetky typy operátorov: selektory cieľov politiky, selektory pod a selektory menného priestoru.

Podsiete a IP adresy (IPBlocks)

Firewally používajú siete VLAN, IP adresy a podsiete na segmentovanie siete.

V Kubernetes sa IP adresy priraďujú k podom automaticky a môžu sa často meniť, takže štítky sa používajú na výber podov a menných priestorov v sieťových politikách.

Podsiete (ipBlocks) sa používajú pri správe prichádzajúcich (vstup) alebo odchádzajúcich (výstupných) externých (severo-južných) spojení. Toto pravidlo sa napríklad otvorí všetkým modulom z menného priestoru default prístup k službe Google DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

Prázdny selektor skupiny v tomto príklade znamená „vybrať všetky skupiny v priestore názvov“.

Táto politika umožňuje prístup len k 8.8.8.8; prístup k akejkoľvek inej IP je zakázaný. V podstate ste teda zablokovali prístup k internej službe Kubernetes DNS. Ak ho napriek tomu chcete otvoriť, výslovne to uveďte.

Obvykle ipBlocks и podSelectors sa navzájom vylučujú, pretože interné IP adresy modulov sa nepoužívajú ipBlocks. Naznačením interné IP moduly, skutočne povolíte pripojenia do/z modulov s týmito adresami. V praxi nebudete vedieť, ktorú IP adresu použiť, a preto by sa nemali používať na výber podov.

Ako protipríklad, nasledujúce zásady zahŕňajú všetky adresy IP, a preto umožňujú prístup ku všetkým ostatným modulom:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

Môžete otvoriť prístup iba k externým IP adresám, s výnimkou interných IP adries modulov. Ak je napríklad podsieť vášho modulu 10.16.0.0/14:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

Porty a protokoly

Moduly zvyčajne počúvajú jeden port. To znamená, že jednoducho nemôžete špecifikovať čísla portov v politikách a nechať všetko ako predvolené. Odporúča sa však, aby boli politiky čo najobmedzujúcejšie, takže v niektorých prípadoch stále môžete zadať porty:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

Všimnite si, že selektor ports platí pre všetky prvky v bloku to alebo from, ktorý obsahuje. Ak chcete určiť rôzne porty pre rôzne sady prvkov, rozdeľte ingress alebo egress do niekoľkých podsekcií s to alebo from a v každej registrácii svoje porty:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

Predvolená operácia portu:

• Ak úplne vynecháte definíciu portu (ports), to znamená všetky protokoly a všetky porty;
• Ak vynecháte definíciu protokolu (protocol), to znamená TCP;
• Ak vynecháte definíciu portu (port), to znamená všetky porty.

Osvedčený postup: Nespoliehajte sa na predvolené hodnoty, explicitne špecifikujte, čo potrebujete.

Upozorňujeme, že musíte použiť porty pod, nie servisné porty (viac o tom v ďalšom odseku).

Sú pravidlá definované pre moduly alebo služby?

Moduly v Kubernetes k sebe zvyčajne pristupujú prostredníctvom služby – virtuálneho nástroja na vyrovnávanie záťaže, ktorý presmeruje prevádzku na moduly, ktoré implementujú službu. Možno si myslíte, že sieťové politiky riadia prístup k službám, ale nie je to tak. Sieťové zásady Kubernetes fungujú na portoch pod, nie na portoch služieb.

Napríklad, ak služba počúva port 80, ale presmeruje prevádzku na port 8080 svojich modulov, v sieťovej politike musí byť špecifikované presne 8080.

Takýto mechanizmus by sa mal považovať za suboptimálny: ak sa zmení vnútorná štruktúra služby (porty ktorých moduly počúvajú), sieťové politiky sa budú musieť aktualizovať.

Nový architektonický prístup využívajúci Service Mesh (napríklad pozri o Istio nižšie - približne preklad.) umožňuje vyrovnať sa s týmto problémom.

Je potrebné registrovať Ingress aj Egress?

Krátka odpoveď je áno, aby modul A mohol komunikovať s modulom B, musí mať povolené vytvoriť odchádzajúce spojenie (na to je potrebné nakonfigurovať politiku výstupu) a modul B musí byť schopný prijať prichádzajúce spojenie ( na to teda potrebujete vstupnú politiku).

V praxi sa však môžete spoľahnúť na predvolenú politiku, ktorá povolí pripojenia v jednom alebo oboch smeroch.

Ak nejaký pod-zdroj bude vybraný jedným alebo viacerými výtok-politici, obmedzenia na ňu kladené budú určené ich disjunkciou. V tomto prípade budete musieť explicitne povoliť pripojenie k modulu -adresátovi. Ak pod nie je vybratá žiadna politika, jeho odchádzajúca (výstupná) prevádzka je predvolene povolená.

Podobne je na tom aj osud luskuadresát, vybrané jedným alebo viacerými vniknutiu-politici, bude určená ich disjunkciou. V takom prípade mu musíte výslovne povoliť prijímať návštevnosť zo zdrojového modulu. Ak pod nie je vybratá žiadna zásada, predvolene je povolená všetka vstupná návštevnosť.

Pozri Stavové alebo Bezstavové nižšie.

Denníky

Sieťové politiky Kubernetes nemôžu zaznamenávať návštevnosť. To sťažuje určenie, či politika funguje podľa plánu, a značne to komplikuje analýzu bezpečnosti.

Riadenie návštevnosti externých služieb

Sieťové zásady Kubernetes vám neumožňujú zadať plne kvalifikovaný názov domény (DNS) vo výstupných sekciách. Táto skutočnosť vedie k značným nepríjemnostiam pri pokuse obmedziť prevádzku na externé ciele, ktoré nemajú pevnú IP adresu (napríklad aws.com).

Kontrola zásad

Firewally vás upozornia alebo dokonca odmietnu prijať nesprávnu politiku. Kubernetes tiež vykonáva určité overenie. Pri nastavovaní sieťovej politiky cez kubectl môže Kubernetes vyhlásiť, že je nesprávna a odmietnuť ju prijať. V ostatných prípadoch Kubernetes prevezme politiku a doplní ju chýbajúcimi podrobnosťami. Môžete ich vidieť pomocou príkazu:

kubernetes get networkpolicy <policy-name> -o yaml

Majte na pamäti, že overovací systém Kubernetes nie je neomylný a môže vynechať niektoré typy chýb.

Prevedenie

Kubernetes sám neimplementuje sieťové politiky, ale je len bránou API, ktorá deleguje bremeno kontroly na základný systém s názvom Container Networking Interface (CNI). Nastavenie politík v klastri Kubernetes bez priradenia príslušného CNI je rovnaké ako vytváranie politík na serveri správy brány firewall bez ich následnej inštalácie na brány firewall. Je na vás, aby ste sa uistili, že máte slušné CNI alebo v prípade platforiem Kubernetes hosťované v cloude (môžete vidieť zoznam poskytovateľov tu - približne. trans.), povoľte sieťové politiky, ktoré vám nastavia CNI.

Upozorňujeme, že Kubernetes vás neupozorní, ak nastavíte sieťovú politiku bez príslušného pomocníka CNI.

Štátny alebo bez štátnej príslušnosti?

Všetky Kubernetes CNI, s ktorými som sa stretol, sú stavové (napríklad Calico používa Linux conntrack). To umožňuje modulu prijímať odpovede na TCP spojenie, ktoré iniciovalo, bez toho, aby ho bolo potrebné znovu nadviazať. Nie som si však vedomý štandardu Kubernetes, ktorý by zaručoval stav.

Pokročilá správa bezpečnostnej politiky

Tu je niekoľko spôsobov, ako zlepšiť presadzovanie bezpečnostných zásad v Kubernetes:

1. Architektonický vzor Service Mesh využíva kontajnery postranných vozíkov na poskytovanie podrobnej telemetrie a riadenia dopravy na úrovni služieb. Ako príklad si môžeme vziať Istio.
2. Niektorí predajcovia CNI rozšírili svoje nástroje tak, aby presahovali sieťové pravidlá Kubernetes.
3. Tufin Orca Poskytuje viditeľnosť a automatizáciu sieťových politík Kubernetes.

Balík Tufin Orca spravuje sieťové politiky Kubernetes (a je zdrojom vyššie uvedených snímok obrazovky).

doplňujúce informácie

• Príklady sieťových politík, ktoré pripravil Ahmet Alp Balkan z GKE;
• Dokumentácia z oficiálnej webovej stránky Kubernetes;
• Sprievodca modelom siete Kubernetes;
• Skript na kontrolu sieťových pravidiel.

Záver

Sieťové politiky Kubernetes ponúkajú dobrú sadu nástrojov na segmentovanie klastrov, ale nie sú intuitívne a majú veľa jemností. Kvôli tejto zložitosti sa domnievam, že mnohé existujúce klastrové politiky sú chybné. Možné riešenia tohto problému zahŕňajú automatizáciu definícií politík alebo použitie iných segmentačných nástrojov.

Dúfam, že táto príručka vám pomôže objasniť niektoré otázky a vyriešiť problémy, s ktorými sa môžete stretnúť.

PS od prekladateľa

Prečítajte si aj na našom blogu:

• "Späť na mikroslužby s Istio": časť 1 (úvod do hlavných funkcií), časť 2 (trasovanie, riadenie dopravy), časť 3 (bezpečnosť);
• "Ilustrovaný sprievodca sieťou v Kubernetes": časti 1 a 2 (model siete, prekryvné siete), časť 3 (služby a spracovanie návštevnosti);
• «Docker a Kubernetes v prostrediach náročných na bezpečnosť»;
• «9 Osvedčené postupy zabezpečenia Kubernetes»;
• «11 spôsobov, ako sa (ne)stať obeťou hacku Kubernetes".

Zdroj: hab.com