Úvod do síťových zásad Kubernetes pro profesionály v oblasti zabezpečení

Poznámka. přel.: Autor článku - Reuven Harrison - má více než 20 let zkušeností s vývojem softwaru a dnes je CTO a spoluzakladatel společnosti Tufin, která se zabývá řešením pro správu bezpečnostní politiky. I když považuje síťové zásady Kubernetes za dostatečně výkonné na to, aby segmentovaly síť v clusteru, zároveň se domnívá, že jejich implementace v praxi není tak snadná. Tento materiál (spíše objemný) má zlepšit informovanost specialistů v této věci a pomoci jim při vytváření potřebných konfigurací.

Dnes mnoho společností stále více volí Kubernetes pro provoz svých aplikací. Zájem o tento software je tak vysoký, že někteří říkají Kubernetes „nový operační systém pro datová centra“. Postupně začíná být Kubernetes (neboli k8) vnímán jako kritická součást podnikání, která vyžaduje organizaci vyspělých obchodních procesů, včetně zabezpečení sítě.

Pro bezpečnostní profesionály, kteří byli zmateni prací s Kubernetes, může být výchozí politika této platformy skutečným objevem: povolit vše.

Tato příručka vám pomůže pochopit vnitřní fungování síťových zásad; pochopit, jak se liší od pravidel pro běžné firewally. Bude také hovořit o některých úskalích a poskytne doporučení, která pomohou chránit aplikace v Kubernetes.

Zásady sítě Kubernetes

Mechanismus síťové politiky Kubernetes umožňuje spravovat interakci aplikací nasazených na platformě na síťové vrstvě (třetí v modelu OSI). Síťové zásady postrádají některé pokročilé funkce moderních firewallů, jako je kontrola OSI vrstvy 7 a detekce hrozeb, ale poskytují základní vrstvu zabezpečení sítě, která je dobrým výchozím bodem.

Síťové zásady řídí komunikaci mezi moduly

Úlohy v Kubernetes jsou distribuovány mezi pody, které se skládají z jednoho nebo více kontejnerů nasazených společně. Kubernetes přiřadí každému podu IP adresu přístupnou z jiných podů. Síťové zásady Kubernetes nastavují přístupová oprávnění pro skupiny podů stejným způsobem, jakým se skupiny zabezpečení v cloudu používají k řízení přístupu k instancím virtuálních strojů.

Definování síťových zásad

Stejně jako ostatní zdroje Kubernetes jsou síťové zásady definovány v YAML. V níže uvedeném příkladu aplikace balance otevírá pří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. přel.: tento screenshot, stejně jako všechny následující podobné screenshoty, nebyl vytvořen pomocí nativních nástrojů Kubernetes, ale pomocí nástroje Tufin Orca, který vyvinula společnost autora původního článku a který je zmíněn na konci materiálu.)

Základní znalost YAML je nutná pro definování vaší vlastní síťové politiky. Tento jazyk je založen na odsazení (určené mezerami, nikoli tabulátory). Odsazený prvek patří nejbližšímu odsazenému prvku nad ním. Nový prvek seznamu začíná pomlčkou, všechny ostatní prvky jsou ve tvaru klíč-hodnota.

Po popisu zásady v YAML použijte kubectlpro jeho vytvoření v clusteru:

kubectl create -f policy.yaml

Specifikace síťových zásad

Specifikace síťových zásad Kubernetes obsahuje čtyři prvky:

1. podSelector: definuje pody ovlivněné touto politikou (cíle) - povinné;
2. policyTypes: označuje, jaké typy politik jsou v této politice zahrnuty: ingress a/nebo egress - volitelné, ale doporučuji to ve všech případech výslovně specifikovat;
3. ingress: definuje povolené příchozí návštěvnost cílových podů – volitelné;
4. egress: definuje povolené odchozí provoz z cílových podů je volitelný.

Příklad vypůjčený z webu Kubernetes (nahradil jsem role na app), ukazuje, jak se používají všechny čtyři 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

Všimněte si, že není nutné zahrnout všechny čtyři prvky. Je to pouze vyžadováno podSelector, zbytek parametrů lze použít podle potřeby.

Pokud vynecháte policyTypes, budou zásady vykládány následovně:

• Ve výchozím nastavení se předpokládá definování vstupní strany. Pokud to zásady výslovně neuvádějí, systém bude předpokládat, že veškerý provoz je zakázán.
• Chování na výstupní straně bude určeno přítomností nebo nepřítomností odpovídajícího výstupního parametru.

Aby nedošlo k chybám, doporučuji být vždy explicitní policyTypes.

Podle logiky výše, v případě parametrů ingress и / nebo egress vynecháte-li, politika odepře veškerý provoz (viz „Pravidlo rozmítání“ níže).

Výchozí politika – povolit

Pokud nejsou definovány žádné zásady, Kubernetes ve výchozím nastavení povoluje veškerý provoz. Všechny moduly si mezi sebou mohou volně vyměňovat informace. Z bezpečnostního hlediska se to může zdát neintuitivní, ale nezapomeňte, že Kubernetes byl původně vytvořen vývojáři s cílem zajistit interoperabilitu aplikací. Síťové zásady byly přidány později.

Jmenné prostory

Jmenné prostory jsou mechanismem spolupráce Kubernetes. Jsou navrženy tak, aby od sebe izolovaly logická prostředí, přičemž ve výchozím nastavení umožňují komunikaci mezi prostory.

Stejně jako většina komponent Kubernetes žijí síťové zásady ve specifickém jmenném prostoru. V bloku metadata můžete určit, do kterého prostoru politika patří:

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

Pokud jmenný prostor není explicitně uveden v metadatech, systém použije jmenný prostor zadaný v kubectl (výchozí namespace=default):

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

doporučuji určete jmenný prostor explicitně, pokud nepíšete politiku, která cílí na více jmenných prostorů najednou.

Primární prvku podSelector v zásadě vybere pody ze jmenného prostoru, do kterého politika patří (nemá přístup k podům z jiného jmenného prostoru).

Podobně podSelectors ve vstupních a výstupních blocích můžete vybrat pody pouze ze svého vlastního jmenného prostoru, pokud je samozřejmě nezkombinujete s namespaceSelector (To bude probráno v části "Filtrovat podle jmenných prostorů a podů").

Pravidla pojmenování zásad

Názvy zásad jsou jedinečné v rámci stejného jmenného prostoru. Ve stejném prostoru nemohou být dvě zásady se stejným názvem, ale v různých prostorech mohou být zásady se stejným názvem. To je užitečné, když chcete znovu použít stejnou zásadu ve více prostorech.

Obzvláště se mi líbí jedna z metod pojmenování. Skládá se ze zřetězení názvu jmenného prostoru s cílovými moduly. Napří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

Vlastní štítky lze připojit k objektům Kubernetes, jako jsou pody a jmenné prostory. Štítky (etikety tagy) jsou ekvivalentem tagů v cloudu. Síťové zásady Kubernetes používají k výběru štítky luskyna které se vztahují:

podSelector:
  matchLabels:
    role: db

… nebo jmenné prostoryna které se vztahují. Tento příklad vybere všechny pody ve jmenných prostorech se shodnými štítky:

namespaceSelector:
  matchLabels:
    project: myproject

Jedno upozornění: při používání namespaceSelector ujistěte se, že jmenné prostory, které vyberete, obsahují správný štítek. Uvědomte si, že vestavěné jmenné prostory jako např default и kube-system, ve výchozím nastavení neobsahují štítky.

Do prostoru můžete přidat štítek takto:

kubectl label namespace default namespace=default

V tomto případě jmenný prostor v sekci metadata by měl odkazovat na skutečný název prostoru, nikoli na štítek:

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

Zdroj a Cíl

Zásady brány firewall se skládají z pravidel zdroje a cíle. Síťové zásady Kubernetes jsou definovány pro každý cíl, sadu modulů, na které se vztahují, a poté nastavují pravidla pro příchozí a/nebo odchozí provoz. V našem příkladu budou cílem zásad všechny pody v oboru názvů default se štítkem klíče app a význam 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

Podsekce ingress v této zásadě otevírá příchozí provoz do cílových podů. Jinými slovy, vstup je zdroj a cíl je odpovídající cíl. Podobně i výstup je cílem a cíl je jeho zdrojem.

To je ekvivalentní dvěma pravidlům brány firewall: Ingress → Target; Cíl → Výstup.

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

Omezení odchozího provozu věnujte zvláštní pozornost DNS - Kubernetes používá tuto službu k mapování služeb na IP adresy. Například následující zásada nebude fungovat, protože jste aplikaci nepovolili balance pří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 opravit otevřením přístupu ke službě 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í prvek to je prázdný, a tak nepřímo volí všechny pody ve všech jmenných prostorech, umožňující balance posílat dotazy DNS na příslušnou službu Kubernetes (obvykle běží v prostoru kube-system).

Tento přístup však funguje přehnaně povolný a nejistý, protože umožňuje směrovat dotazy DNS mimo cluster.

Vylepšit ji můžete ve třech po sobě jdoucích krocích.

1. Povolit pouze dotazy DNS uvnitř shlukovat přidání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. Povolte dotazy DNS pouze ve jmenném prostoru kube-system.

Chcete-li to provést, musíte do jmenného prostoru přidat štítek kube-system: kubectl label namespace kube-system namespace=kube-system - a zaregistrujte jej v zásadě pomocí 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. Paranoidi mohou jít ještě dále a omezit požadavky DNS na konkrétní službu DNS v kube-system. Sekce "Filtrovat podle jmenných prostorů A podů" vám ukáže, jak toho dosáhnout.

Další možností je překlad DNS na úrovni jmenného prostoru. V tomto případě jej nebude nutné otevírat pro každou 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ázdný podSelector vybere všechny pody ve jmenném prostoru.

První zápas a pořadí pravidel

V konvenčních firewallech je akce (Povolit nebo Zakázat) na paket určena prvním pravidlem, které vyhovuje. V Kubernetes na pořadí zásad nezáleží.

Ve výchozím nastavení, když nejsou nastaveny žádné zásady, je komunikace mezi moduly povolena a mohou si volně vyměňovat informace. Jakmile začnete formulovat zásady, každý modul ovlivněný alespoň jednou z nich se izoluje podle disjunkce (logické NEBO) všech zásad, které jej zvolily. Pody, které nejsou ovlivněny žádnou politikou, zůstávají otevřené.

Toto chování můžete změnit pomocí pravidla tažení.

Pravidlo čištění ("Zakázat")

Zásady brány firewall obvykle odmítají jakýkoli provoz, který není výslovně povolen.

Kubernetes nemá akci „odmítnout“., ale stejného efektu lze dosáhnout s normální (povolenou) politikou výběrem prázdné skupiny zdrojových modulů (vstup):

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

Tato zásada vybere všechny pody v oboru názvů a ponechá vstup nedefinovaný, čímž zakáže veškerý příchozí provoz.

Podobně můžete omezit veškerý odchozí provoz z oboru názvů:

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

Upozorňujeme, že jakékoli další zásady, které umožňují provoz do podů ve jmenném prostoru, budou mít přednost před tímto pravidlem (podobně jako přidání pravidla povolení před pravidlo odmítnutí v konfiguraci brány firewall).

Povolit vše (Any-Any-Any-Allow)

Chcete-li vytvořit zásadu „Povolit vše“, musíte výše uvedenou zásadu odmítnutí doplnit prázdným prvkem ingress:

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

Poskytuje přístup k všechny pody ve všech jmenných prostorech (a všechny IP adresy) na jakýkoli pod ve jmenném prostoru default. Toto chování je ve výchozím nastavení povoleno, takže jej obvykle není třeba dále definovat. Někdy však může být nutné dočasně zakázat určitá specifická oprávnění, aby bylo možné diagnostikovat problém.

Pravidlo lze zúžit tak, aby umožňovalo přístup pouze k konkrétní sadu lusků (app:balance) ve jmenném prostoru default:

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

Následující zásady povolují veškerý příchozí (příchozí) A odchozí (výstupní) provoz, včetně přístupu k libovolné IP adrese mimo cluster:

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

Kombinace více zásad

Zásady jsou logicky OR na třech úrovních; Oprávnění každého podu jsou nastavena podle disjunkce všech zásad, které jej ovlivňují:

1. Na polích from и to lze definovat tři typy prvků (vše v kombinaci s OR):

• namespaceSelector - vybere celý jmenný prostor;
• podSelector - vybírá lusky;
• ipBlock - vybere podsíť.

Zároveň počet prvků (i stejných) v podsekcích from/to neomezená. Všechny budou kombinovány s logickým OR.

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. Vnitřní politika ingress může mít mnoho prvků from (kombinováno logickým OR). Podobně oddíl egress může obsahovat mnoho prvků to (také kombinováno disjunkcí):

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ůzné politiky jsou také kombinovány s logickým OR

Ale když jsou kombinovány, existuje jedno omezení poukázal Chris Cooney: Kubernetes může kombinovat pouze zásady s různými policyTypes (Ingress nebo Egress). Zásady, které definují vstup (nebo výstup) se navzájem přepíší.

Vztah mezi jmennými prostory

Ve výchozím nastavení je výměna informací mezi jmennými prostory povolena. To lze změnit pomocí restriktivní zásady, která omezuje odchozí a/nebo příchozí provoz do jmenného prostoru (viz „Pravidlo rozmítání“ výše).

Zablokováním přístupu k jmennému prostoru (viz „Pravidlo zametání“ výše) můžete udělat výjimky ze zásady odmítnutí tím, že povolíte připojení z konkrétního jmenného prostoru pomocí 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ýsledkem je, že všechny pody ve jmenném prostoru default získat přístup k modulům postgres ve jmenném prostoru database. Ale co když chcete otevřít přístup k postgres pouze konkrétní pody ve jmenném prostoru default?

Filtrujte podle jmenných prostorů A podů

Kubernetes verze 1.11 a vyšší umožňuje kombinovat operátory namespaceSelector и podSelector pomocí logického AND. Vypadá 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

Proč se vykládá jako AND namísto obvyklého NEBO?

Vezměte prosím na vědomí, že podSelector nezačíná pomlčkou. V YAML to znamená podSelector a stojí před ním namespaceSelector odkazovat na stejný prvek seznamu. Proto jsou kombinovány s logickým AND.

Před přidáním pomlčky podSelector výsledkem bude nový prvek seznamu, který bude zkombinován s předchozím namespaceSelector pomocí logického OR.

Chcete-li vybrat pody s konkrétním štítkem ve všech jmenných prostorech, zadejte prázdné 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

Kombinace více štítků s AND

Pravidla brány firewall s více entitami (hostitelé, sítě, skupiny) jsou kombinována pomocí logického OR. Následující pravidlo se spustí, pokud se zdroj paketu shoduje Host_1 OR Host_2:

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

Naopak v Kubernetes různé štítky v podSelector nebo namespaceSelector jsou kombinovány s logickým AND. Například následující pravidlo vybere pody, které mají oba štítky, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Stejná logika platí pro všechny typy příkazů: selektory cílů zásad, selektory podů a selektory jmenného prostoru.

Podsítě a IP adresy (IPBlocks)

Firewally používají VLAN, IP adresy a podsítě k segmentaci sítě.

V Kubernetes jsou IP adresy automaticky přidělovány podům a mohou se často měnit, takže k výběru podů a jmenných prostorů v síťových zásadách se používají štítky.

Podsítě (ipBlocks) se používají při správě příchozích (vstup) nebo odchozích (odchozích) externích (sever-jih) připojení. Tato zásada například otevře všechny pody z oboru názvů default přístup ke službě 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

Volič prázdných podů v tomto příkladu znamená „vybrat všechny pody ve jmenném prostoru“.

Tato politika umožňuje přístup pouze k 8.8.8.8; přístup k jakékoli jiné IP je zakázán. V podstatě jste tedy zablokovali přístup k interní službě Kubernetes DNS. Pokud jej přesto chcete otevřít, určete to explicitně.

Obvykle ipBlocks и podSelectors se vzájemně vylučují, protože interní IP adresy modulů se nepoužívají ipBlocks. Poukazuje interní IP moduly, skutečně povolíte připojení do/z modulů s těmito adresami. V praxi nebudete vědět, kterou IP adresu použít, a proto byste je neměli používat k výběru podů.

Jako příklad počítadla následující zásady zahrnují všechny IP adresy, a proto umožňují přístup ke všem ostatním podům:

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 otevřít přístup pouze k externím IP adresám, s výjimkou interních IP adres modulů. Pokud je například podsíť vašeho podu 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

Obvykle moduly poslouchají na jednom portu. To znamená, že můžete jednoduše vynechat čísla portů ve svých zásadách a nechat vše jako výchozí. Doporučuje se však, aby zásady byly co nejvíce omezující, takže v některých případech stále můžete zadat 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šimněte si, že volič ports platí pro všechny prvky v bloku to nebo from, který obsahuje. Chcete-li zadat různé porty pro různé sady položek, přerušte ingress nebo egress do několika podsekcí to nebo from a do každého zapište své 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

Výchozí porty fungují:

• Pokud úplně vynecháte definici portů (ports), což znamená všechny protokoly a všechny porty;
• Pokud vynecháte definici protokolu (protocol), což znamená TCP;
• Pokud vynecháte definici portu (port), což znamená všechny porty.

Osvědčený postup: Nespoléhejte se na výchozí hodnoty, určete, co výslovně potřebujete.

Všimněte si, že musíte používat porty pod, nikoli služby (více o tom v dalším odstavci).

Zásady definované pro pody nebo služby?

Obvykle pody v Kubernetes mezi sebou komunikují prostřednictvím služby – virtuálního nástroje pro vyrovnávání zatížení, který přesměrovává provoz na pody, které službu implementují. Možná si myslíte, že síťové zásady řídí přístup ke službám, ale není tomu tak. Síťové zásady Kubernetes fungují s porty pod, nikoli službami.

Pokud například služba naslouchá na portu 80, ale přesměruje provoz na port 8080 svých modulů, musíte zadat 8080 v zásadách sítě.

Takový mechanismus by měl být považován za neoptimální: pokud se změní vnitřní zařízení služby (jejíž porty naslouchají modulům), bude nutné aktualizovat síťové zásady.

Nový architektonický přístup pomocí Service Mesh (např. viz o Istio níže - cca překlad.) umožňuje se s tímto problémem vypořádat.

Je nutné psát Ingress i Egress?

Krátká odpověď zní ano, aby modul A mohl komunikovat s modulem B, musíte mu povolit vytvoření odchozího připojení (k tomu musíte nakonfigurovat politiku odchozího hovoru) a modul B musí být schopen přijímat příchozí připojení. (k tomu tedy potřebujete ingress- policy).

V praxi se však můžete spolehnout na to, že výchozí politika povolí připojení v jednom nebo obou směrech.

Pokud nějaký pod-zdroj bude vybrán jedním nebo více výtok-politici, omezení na ni kladená budou určena jejich disjunkcí. V tomto případě budete muset výslovně povolit připojení k moduluadresát. Pokud pod není vybrán žádnou zásadou, je jeho odchozí (výstupní) provoz ve výchozím nastavení povolen.

Podobně osud pod'a-adresátvybrané jedním nebo více vniknutí-politiky budou určeny jejich disjunkcí. V tomto případě mu musíte výslovně povolit příjem provozu ze zdrojového podu. Pokud pod není vybrána žádná zásada, je ve výchozím nastavení povolen veškerý příchozí provoz.

Viz „Stateful or Stateless“ níže.

Protokoly

Síťové zásady Kubernetes nevědí, jak protokolovat provoz. To ztěžuje určení, zda politika funguje podle očekávání, a velmi ztěžuje analýzu zabezpečení.

Řízení provozu na externí služby

Síťové zásady Kubernetes neumožňují zadat plně kvalifikovaný název domény (DNS) ve výstupních sekcích. Tato skutečnost vede k výraznému nepohodlí při pokusu o omezení provozu na externí cíle, které nemají pevnou IP adresu (např. aws.com).

Kontrola zásad

Firewally vás upozorní nebo dokonce odmítnou přijmout chybnou politiku. Kubernetes také provádí nějaké ověření. Při nastavování síťových zásad přes kubectl může Kubernetes prohlásit, že zásady jsou nesprávné, a odmítnout je přijmout. V ostatních případech Kubernetes převezme zásady a doplní je chybějícími podrobnostmi. Můžete je vidět pomocí příkazu:

kubernetes get networkpolicy <policy-name> -o yaml

Mějte na paměti, že ověřovací systém Kubernetes není neomylný a může vynechat některé typy chyb.

Provedení

Kubernetes sám o sobě nevynucuje síťové zásady, ale je pouze bránou API, která klade zátěž kontroly na základní systém zvaný CNI (Container Networking Interface). Nastavení zásad na clusteru Kubernetes bez přiřazení vhodného CNI je podobné jako nastavování zásad na serveru pro správu brány firewall, aniž byste je následně nastavovali na brány firewall. Je na vás, abyste zajistili, že máte slušné CNI nebo v případě platforem Kubernetes hostované v cloudu (Seznam poskytovatelů viz zde - Cca. trans.), povolte síťové zásady, které nastaví CNI za vás.

Všimněte si, že Kubernetes vás neupozorní, pokud nastavíte síťové zásady bez příslušného pomocníka CNI.

Státní nebo bez státní příslušnosti?

Všechny Kubernetes CNI, na které jsem narazil, jsou stavové (například Calico používá Linux conntrack). To umožňuje modulu přijímat odpovědi na TCP spojení, které inicioval, aniž by bylo nutné jej znovu navazovat. Nejsem si však vědom standardu Kubernetes, který by zaručoval stavovost.

Pokročilá správa bezpečnostních zásad

Zde je několik způsobů, jak zlepšit efektivitu prosazování zásad zabezpečení v Kubernetes:

1. Architektonický vzor Service Mesh využívá postranní vozíky k poskytování podrobné telemetrie a řízení provozu na úrovni služeb. Jako příklad si lze vzít Stejný.
2. Někteří dodavatelé CNI rozšířili své nástroje tak, aby šly nad rámec síťových zásad Kubernetes.
3. Kosatec tufinský poskytuje transparentnost a automatizaci síťových zásad Kubernetes.

Balíček Tufin Orca spravuje síťové zásady Kubernetes (a je zdrojem výše uvedených snímků obrazovky).

doplňující informace

• Příklady síťové politiky připravené Ahmetem Alpem Balkanem z GKE;
• Dokumentace z oficiálního webu Kubernetes;
• Průvodce síťovým modelem Kubernetes;
• Skript pro kontrolu síťových zásad.

Závěr

Síťové zásady Kubernetes nabízejí dobrou sadu nástrojů pro segmentaci clusterů, ale nejsou intuitivní a mají mnoho jemností. Domnívám se, že kvůli této složitosti jsou politiky mnoha existujících klastrů chybné. Možnými řešeními tohoto problému je automatizace definic politik nebo použití jiných segmentačních nástrojů.

Doufám, že vám tato příručka pomůže objasnit některé otázky a vyřešit problémy, se kterými se můžete setkat.

PS od překladatele

Přečtěte si také na našem blogu:

• "Zpět na mikroslužby s Istio": část 1 (úvod do hlavních funkcí), část 2 (trasování, řízení dopravy), část 3 (zabezpečení);
• "Ilustrovaný průvodce sítí v Kubernetes": části 1 a 2 (model sítě, překryvné sítě), část 3 (služby a zpracování provozu);
• «Docker a Kubernetes v prostředích náročných na zabezpečení";
• «9 Doporučené postupy zabezpečení Kubernetes";
• «11 způsobů, jak se (ne)nabourat v Kubernetes".

Zdroj: www.habr.com