Pochopení možností vynucení síťových zásad s Calico

Síťový plugin Calico poskytuje širokou škálu síťových zásad s jednotnou syntaxí pro ochranu hardwarových hostitelů, virtuálních strojů a modulů. Tyto zásady lze použít v rámci jmenného prostoru nebo to mohou být zásady globální sítě, na které se vztahují hostitelský koncový bod (pro ochranu aplikací běžících přímo na hostiteli - hostitelem může být server nebo virtuální stroj) popř koncový bod pracovní zátěže (k ochraně aplikací běžících v kontejnerech nebo hostovaných virtuálních strojích). Zásady Calico vám umožňují aplikovat bezpečnostní opatření v různých bodech cesty paketu pomocí možností, jako je preDNAT, unraraced a applyOnForward. Pochopení toho, jak tyto volby fungují, může pomoci zlepšit zabezpečení a výkon celého systému. Tento článek vysvětluje podstatu těchto možností zásad Calico (preDNAT, unraraced a applyOnForward) aplikovaných na koncové body hostitele, s důrazem na to, co se děje v cestách zpracování paketů (řetězce iptabels).

Tento článek předpokládá, že máte základní znalosti o tom, jak fungují síťové zásady Kubernetes a Calico. Pokud ne, doporučujeme vyzkoušet základní kurz síťové politiky и výukový program ochrany hostitele pomocí Calico, než si přečtete tento článek. Očekáváme také, že budete mít základní znalosti o práci iptables v linuxu.

Kaliko globální síťová politika umožňuje použít sadu přístupových pravidel podle štítků (na skupiny hostitelů a pracovní zátěže/pody). To je velmi užitečné, pokud společně používáte heterogenní systémy – virtuální stroje, systém přímo na hardwaru nebo infrastrukturu kubernetes. Kromě toho můžete svůj cluster (uzly) chránit pomocí sady deklarativních zásad a aplikovat síťové zásady na příchozí provoz (například prostřednictvím služby NodePorts nebo External IPs).

Na základní úrovni, když Calico připojí modul k síti (viz schéma níže), připojí jej k hostiteli pomocí virtuálního rozhraní Ethernet (veth). Provoz odesílaný modulem přichází k hostiteli z tohoto virtuálního rozhraní a je zpracováván stejným způsobem, jako by pocházel z fyzického síťového rozhraní. Ve výchozím nastavení Calico pojmenuje tato rozhraní caliXXX. Protože provoz přichází přes virtuální rozhraní, prochází přes iptables, jako by pod byl jeden skok daleko. Proto, když provoz přichází do/z podu, je předán z pohledu hostitele.

Na uzlu Kubernetes se systémem Calico můžete namapovat virtuální rozhraní (veth) k pracovní zátěži následovně. V příkladu níže můžete vidět, že veth#10 (calic1cbf1ca0f8) je připojen k cnx-manager-* ve jmenném prostoru calico-monitoring.

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m                            ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...

Vzhledem k tomu, že Calico vytváří rozhraní veth pro každou pracovní zátěž, jak vynucuje zásady? Za tímto účelem Calico vytváří háčky v různých řetězcích cesty zpracování paketů pomocí iptables.

Níže uvedený diagram ukazuje řetězce zapojené do zpracování paketů v iptables (nebo subsystému netfilter). Když paket dorazí přes síťové rozhraní, nejprve prochází řetězcem PREROUTING. Poté je učiněno rozhodnutí o směrování a na základě toho paket prochází buď INPUT (směrován na hostitelské procesy) nebo VPŘED (směrován do podu nebo jiného uzlu v síti). Z místního procesu paket prochází OUTPUT a poté POSTROUTING řetězcem, než je odeslán po kabelu.

Všimněte si, že pod je také externí entita (připojená k veth) z hlediska zpracování iptables. Pojďme si to shrnout:

• Přesměrovaný provoz (nat, směrovaný nebo do/z pod) prochází řetězci PREROUTING - FORWARD - POSTROUTING.
• Provoz na proces místního hostitele prochází řetězcem PREROUTING - INPUT.
• Provoz z místního hostitelského procesu prochází řetězcem OUTPUT - POSTROUTING.

Calico poskytuje možnosti zásad, které vám umožňují aplikovat zásady napříč všemi řetězci. S ohledem na to se podívejme na různé možnosti konfigurace zásad dostupné v Calico. Čísla v seznamu možností níže odpovídají číslům na obrázku výše.

1. Zásady koncového bodu zátěže (pod).
2. Zásady hostitelského koncového bodu
3. Možnost ApplyOnForward
4. Zásady PreDNAT
5. Nesledované zásady

Začněme tím, že se podíváme na to, jak se zásady aplikují na koncové body pracovního zatížení (pody Kubernetes nebo virtuální počítače OpenStack), a pak se podíváme na možnosti zásad pro koncové body hostitele.

Koncové body pracovní zátěže

Zásady koncového bodu zátěže (1)

Toto je možnost ochrany vašich modulů kubernetes. Calico podporuje práci s Kubernetes NetworkPolicy, ale poskytuje také další zásady – Calico NetworkPolicy a GlobalNetworkPolicy. Calico vytvoří řetězec pro každý modul (pracovní zátěž) a zavěsí v řetězcích INPUT a OUTPUT pro pracovní zatížení na filtrační stůl řetězce FORWARD.

Hostitelské koncové body

Zásady hostitelského koncového bodu (2)

Kromě CNI (kontejnerové síťové rozhraní) poskytují zásady Calico možnost chránit samotného hostitele. V Calico můžete vytvořit koncový bod hostitele zadáním kombinace hostitelského rozhraní a v případě potřeby čísel portů. Vynucení zásad pro tuto entitu je dosaženo pomocí tabulky filtrů v řetězcích INPUT a OUTPUT. Jak můžete vidět z diagramu, (2) platí pro lokální procesy na uzlu/hostiteli. To znamená, že pokud vytvoříte politiku, která se vztahuje na koncový bod hostitele, neovlivní provoz směřující do/z vašich podů. Poskytuje však jediné rozhraní/syntaxi pro blokování provozu pro vašeho hostitele a moduly pomocí zásad Calico. To značně zjednodušuje proces správy politik pro heterogenní síť. Dalším důležitým případem použití je konfigurace zásad hostitelského koncového bodu pro zvýšení zabezpečení clusteru.

Zásady ApplyOnForward (3)

Možnost ApplyOnForward je k dispozici v zásadách globální sítě Calico, která umožňuje aplikovat zásady na veškerý provoz procházející koncovým bodem hostitele, včetně provozu, který bude předáván hostitelem. To zahrnuje provoz přesměrovaný na místní modul nebo kamkoli jinam v síti. Calico vyžaduje, aby bylo toto nastavení povoleno pro zásady používající PreDNAT a untracked, viz následující sekce. Aplikaci ApplyOnForward lze navíc použít k monitorování hostitelského provozu v případech, kdy je použit virtuální router nebo softwarový NAT.

Všimněte si, že pokud potřebujete použít stejnou síťovou politiku na hostitelské procesy i pody, nemusíte používat volbu ApplyOnForward. Vše, co musíte udělat, je vytvořit štítek pro požadovaný hostendpoint a koncový bod zátěže (pod). Calico je dostatečně chytré na to, aby prosadilo politiku založenou na štítcích, bez ohledu na typ koncového bodu (hostendpoint nebo pracovní zátěž).

Zásady PreDNAT (4)

V Kubernetes lze porty entit služeb zpřístupnit externě pomocí možnosti NodePorts nebo volitelně (při použití Calico) jejich inzerováním pomocí možností Cluster IPs nebo External IPs. Kube-proxy vyrovnává příchozí provoz vázaný na službu do podů odpovídající služby pomocí DNAT. Vzhledem k tomu, jak vynucujete zásady pro provoz přicházející přes NodePorts? Aby bylo zajištěno, že tyto zásady budou aplikovány před zpracováním provozu DNAT (což je mapování mezi hostitelem:port a odpovídající službou), Calico poskytuje parametr pro globalNetworkPolicy nazvaný "preDNAT: true".

Když je povolena pre-DNAT, jsou tyto zásady implementovány v (4) v diagramu - v mandlové tabulce řetězce PREROUTING - bezprostředně před DNAT. Zde není dodržováno obvyklé pořadí zásad, protože aplikace těchto zásad nastává mnohem dříve v cestě zpracování provozu. Zásady preDNAT však respektují pořadí aplikací mezi sebou.

Při vytváření zásad s pre-DNAT je důležité dávat pozor na provoz, který chcete zpracovat, a umožnit odmítnutí většiny. Provoz označený jako 'povolený' v zásadách před DNAT již nebude kontrolován zásadou hostitelského bodu, zatímco provoz, který zásadou před DNAT selže, bude pokračovat ve zbývajících řetězcích.
Calico zavedlo povinné povolení volby applyOnForward při použití preDNAT, protože podle definice ještě nebyl vybrán cíl provozu. Provoz může být směrován do hostitelského procesu nebo může být předán pod nebo jinému uzlu.

Nesledované zásady (5)

Sítě a aplikace mohou mít velké rozdíly v chování. V některých extrémních případech mohou aplikace generovat mnoho krátkodobých připojení. To může způsobit, že conntrack (základní součást linuxového síťového zásobníku) bude nedostatek paměti. Pro spouštění těchto typů aplikací v Linuxu byste tradičně museli ručně nakonfigurovat nebo zakázat conntrack nebo napsat pravidla iptables, abyste conntrack obcházeli. Nesledovaná politika v Calico je jednodušší a efektivnější možnost, pokud chcete zpracovat připojení co nejrychleji. Například pokud používáte masivní memcache nebo jako doplňkové ochranné opatření proti DDOS.

Přečti si tohle blogu (nebo náš překlad) pro více informací, včetně testů výkonu pomocí nesledovaných zásad.

Když v Calico globalNetworkPolicy nastavíte možnost „doNotTrack: true“, stane se **nesledovanou** zásadou a použije se velmi brzy v procesu zpracování paketů Linuxu. Při pohledu na výše uvedený diagram jsou nesledované zásady aplikovány v řetězcích PREROUTING a OUTPUT v nezpracované tabulce před zahájením sledování připojení (conntrack). Když je paket povolen zásadou nesledování, je označen, aby bylo zakázáno sledování připojení pro daný paket. To znamená:

• Nesledovaná zásada se aplikuje na jednotlivé pakety. Neexistuje žádný koncept spojení (nebo toku). Nedostatek spojení má několik důležitých důsledků:
• Chcete-li povolit provoz požadavků i odpovědí, potřebujete pravidlo pro příchozí i odchozí (protože Calico obvykle používá conntrack k označení provozu odpovědí jako povoleného).
• Nesledovaná zásada nefunguje pro úlohy Kubernetes (pody), protože v tomto případě neexistuje způsob, jak sledovat odchozí připojení z pod.
• NAT nefunguje správně s nesledovanými pakety (protože jádro ukládá mapování NAT v conntrack).
• Při průchodu pravidlem „povolit vše“ v zásadě untracked budou všechny pakety označeny jako nesledované. Téměř vždy to není to, co chcete, takže je důležité být velmi selektivní, pokud jde o pakety povolené nesledovanými politikami (a umožnit většině provozu procházet normálními sledovanými politikami).
• Nesledované zásady jsou aplikovány na samém začátku procesu zpracování paketů. To je velmi důležité pochopit při vytváření zásad Calico. Můžete mít zásady pod s order:1 a nesledované zásady s order:1000. To bude jedno. Před zásadou pro pod bude použita zásada Nesledováno. Nesledované zásady respektují příkaz k provedení pouze mezi sebou.

Protože jedním z účelů zásady doNotTrack je vynutit tuto zásadu velmi brzy v procesu zpracování paketů Linuxu, Calico vyžaduje, aby bylo při používání doNotTrack povinné zadat volbu applyOnForward. S odkazem na diagram zpracování paketů si všimněte, že před jakýmkoli rozhodnutím o směrování se použije zásada untracked(5). Provoz může být směrován do hostitelského procesu nebo může být předán pod nebo jinému uzlu.

Výsledky

Podívali jsme se na různé možnosti zásad (koncový bod hostitele, ApplyOnForward, preDNAT a Untracked) v Calico a na to, jak jsou aplikovány na cestě zpracování paketů. Pochopení toho, jak fungují, pomáhá při vytváření účinných a bezpečných politik. S Calico můžete použít globální síťovou politiku, která se vztahuje na štítek (skupinu uzlů a podů) a aplikovat zásady s různými parametry. To umožňuje profesionálům v oblasti zabezpečení a návrhu sítě pohodlně chránit „vše“ (typy koncových bodů) najednou pomocí jediného jazyka zásad se zásadami Calico.

Poděkování: Rád bych poděkoval Sean Crampton и Alexa Pollitta za jejich recenzi a cenné informace.

Zdroj: www.habr.com