Síťový plugin Calico poskytuje širokou škálu síťových pravidel s jednotnou syntaxí pro ochranu hostitelů na hardwaru, virtuálních strojích a podech. Tato pravidla mohou být aplikována v rámci namespace nebo mohou být globálními síťovými pravidly, která se vztahují na (pro ochranu aplikací běžících přímo na hostu - hostem může být buď server, nebo virtuální stroj) nebo na (pro ochranu aplikací běžících v kontejnerech nebo virtuálních strojích umístěných na hostu). Pravidla Calico umožňují aplikaci bezpečnostních opatření pro různé cesty paketů pomocí parametrů jako preDNAT, unraracked a applyOnForward. Porozumění tomu, jak tyto možnosti fungují, může pomoci zlepšit zabezpečení a výkonnost systému jako celku. V tomto článku je vysvětleno jádro těchto parametrů pravidel Calico (preDNAT, unraracked a applyOnForward) aplikovaných na host endpoints, se zaměřením na to, co se děje v cestách zpracování paketů (řetězících iptables).
Tento článek předpokládá, že máte pochopení základních principů fungování síťových pravidel Kubernetes a Calico. Pokud ne, doporučujeme vyzkoušet a použití Calico, než si přečtete tento článek. Také předpokládáme, že máte základní znalosti o Linuxu.
Calico vám umožňuje aplikovat soubor pravidel přístupu podle štítků (na skupiny hostitelů a workloads/podů). To je velmi užitečné, pokud používáte různé systémy - virtuální stroje, systém přímo na hardwaru nebo infrastrukturu Kubernetes. Navíc můžete chránit svůj cluster (uzly) pomocí sady deklarativních pravidel a aplikovat síťová pravidla na příchozí provoz (například přes služby NodePorts nebo externí IP).
Na základní úrovni, když Calico připojuje pod k síti (viz diagram níže), připojuje ho k hostiteli pomocí virtuálního Ethernet rozhraní (veth). Procházející provoz z podu přichází na hostitele z tohoto virtuálního rozhraní a je zpracován stejně, jako kdyby přišel z fyzického síťového rozhraní. Ve výchozím nastavení Calico nazývá tato rozhraní caliXXX. Protože provoz přichází prostřednictvím virtuálního rozhraní, prochází iptables, jako by se pod nacházel na jedné hopové vzdálenosti. Takže když provoz přichází/odchází od podu, je přeposílán (forwarded) z pohledu hostitele.
Na Kubernetes nodě, na které běží Calico, můžete přiřadit virtuální rozhraní (veth) k workloadu následujícím způsobem. Na následujícím příkladu můžete vidět, že veth#10 (calic1cbf1ca0f8) je připojeno k cnx-manager-* v calico-monitoring namespace.
[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: 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áří veth rozhraní pro každý workload, jak aplikuje politiky? Za tímto účelem Calico vytváří hooky do různých řetězců cesty zpracování paketů pomocí iptables.
Na diagramu níže jsou znázorněny řetězce zapojené do zpracování paketů v iptables (nebo v subsystému netfilter). Když paket přichází přes síťové rozhraní, nejprve prochází řetězcem PREROUTING. Poté se rozhoduje o směrování a na základě toho paket prochází buď přes INPUT (směřující na procesy hostitele), nebo přes FORWARD (směřující na pod nebo jinou nodu v síti). Z místního procesu paket prochází řetězcem OUTPUT a poté POSTROUTING před odesláním po kabelu.
Všimněte si, že pod je také externí objekt (připojený k veth) z pohledu zpracování iptables. Shrňme to:
- Přeposílán (forwarded) provoz (nat, směrovaný nebo do/z podu) prochází řetězci PREROUTING — FORWARD — POSTROUTING.
- Provoz na místní hostitelský proces prochází řetězcem PREROUTING — INPUT.
- Provoz od místního hostitelského procesu prochází řetězcem OUTPUT — POSTROUTING.
Calico poskytuje možnosti politik, pomocí kterých lze aplikovat politiky na všechny řetězce. Mějte to na paměti, pojďme se podívat na různé možnosti nastavení politik, které jsou dostupné v Calico. Čísla v seznamu možností níže odpovídají číslům na výše uvedeném diagramu.
- Politika koncového bodu pracovního zatížení (pod)
- Politika koncového bodu hostitele
- Možnost ApplyOnForward
- Politika PreDNAT
- Politika Untracked
Začněme tím, jak se politiky aplikují na koncové body pracovního zatížení (pod Kubernetes nebo VMs OpenStack), a poté se podívejme na možnosti politik pro koncové body hostitelů.
Koncové body pracovního zatížení
Politika koncového bodu pracovního zatížení (1)
Toto je možnost pro ochranu vašich podů Kubernetes. Calico podporuje práci s Kubernetes NetworkPolicy, ale také poskytuje další politiky — Calico NetworkPolicy a GlobalNetworkPolicy. Calico vytváří řetězec pro každý pod (pracovní zatížení) a zavádí háky do řetězců INPUT a OUTPUT pro pracovního zatížení do tabulky filtrů řetězce FORWARD.
Koncové body hostitele
Politika koncového bodu hostitele (2)
Kromě CNI (interface pro síť kontejnerů) poskytují politiky Calico možnost ochrany přímo hostitele. V Calico můžete vytvořit koncový bod hostitele zadáním kombinace z rozhraní hostitele a, pokud je to potřeba, portových čísel. Aplikace politik pro tuto entitu se dosahuje pomocí tabulky filtrů v řetězcích INPUT a OUTPUT. Jak je vidět z diagramu, (2) jsou aplikovány na místní procesy na uzlu/hostiteli. To znamená, že pokud vytvoříte politiku, která se aplikuje na koncový bod hostitele, nebude mít vliv na provoz směřující k/od vašich podů. Ale skrze to se zajišťuje jednotné rozhraní/syntax pro blokování provozu pro váš hostitel a pody pomocí politik Calico. To významně zjednodušuje proces správy politik pro heterogenní síť. Nastavení politik koncového bodu hostitele pro zvýšení ochrany clusteru je další důležitou možností jejich využití.
Politika ApplyOnForward (3)
Možnost ApplyOnForward je dostupná v globální síťové politice Calico, aby umožnila aplikaci politik na veškerý provoz procházející koncovým bodem hostitele, včetně provozu, který bude hostitelem přesměrován. Tento provoz zahrnuje přeposlaný do místního podu nebo jinam do sítě. Calico vyžaduje, aby byl tento parametr povolen pro politiky používající PreDNAT a untracked, viz následující části. Kromě toho lze ApplyOnForward použít pro sledování provozu hostitele v případech použití virtuálního routeru nebo softwarového NAT.
Všimněte si, že pokud potřebujete aplikovat stejnou síťovou politiku pro hostitelské procesy i pro pod'y, nemusíte používat možnost ApplyOnForward. Stačí vytvořit label pro potřebné hostendpoint a workload endpoint (pod). Calico je dostatečně chytrý, aby aplikoval politiku na základě labels, bez ohledu na typ endpointu (hostendpoint nebo workload).
PreDNAT Politika (4)
V Kubernetes mohou být porty entity service vyvedeny ven pomocí možnosti NodePorts nebo volitelně (při použití Calico) prostřednictvím jejich deklarace pomocí možností Cluster IPs nebo External IPs. Kube-proxy vyvažuje příchozí provoz, přidružený k service, k pod'ům odpovídajících service, pomocí DNAT. Vzhledem k tomu, jak tedy aplikujete politiky pro provoz přicházející přes NodePorts? Aby tyto politiky byly aplikovány předtím, než bude provoz zpracován DNAT (což představuje mapování host:port a odpovídající service), Calico poskytuje parametr pro globalNetworkPolicy, který se nazývá „preDNAT: true“.
Když je pre-DNAT zapnutý, tyto politiky se implementují v (4) na diagramu — v tabulce mangle řetězce PREROUTING — přímo před DNAT. Běžný pořádek politik (order) zde není dodržován, protože aplikace těchto politik probíhá mnohem dříve v cestě zpracování provozu. Nicméně, politiky preDNAT dodržují pořadí aplikace (order) mezi sebou.
Při vytváření politik s pre-DNAT je důležité být obezřetný vůči provozu, který chcete zpracovat, a umožnit většině být odmítnuta. Provoz označený jako 'allow' v politice pre-DNAT již nebude kontrolován hostendpoint politikou, zatímco provoz, který neprojde politikou pre-DNAT, bude pokračovat cestou skrze další řetězce.
Calico učinil povinným zapnout možnost applyOnForward při používání preDNAT, protože podle definice cílový provoz ještě nebyl vybrán. Provoz může být směrován na hostitelský proces, nebo může být přesměrován na pod nebo na jiný uzel.
Untracked Politika (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 množství krátkodobých připojení. To může vést k nedostatku paměti u conntrack (základní součást síťového zásobníku Linuxu). Tradičně pro spuštění takových aplikací v systému Linux je nutné ručně nastavit nebo vypnout conntrack, nebo napsat pravidla iptables, abyste se vyhnuli conntracku. Politika Untracked v Calico je jednodušší a efektivnější možnost, pokud chcete zpracovávat připojení co nejrychleji. Například, pokud používáte masivní nebo jako další opatření k ochraně před .
Přečtěte si tento (nebo ) pro další informace, včetně testů výkonnosti při použití untracked policy.
Když nastavíte možnost „doNotTrack: true“ v Calico globalNetworkPolicy, stává se **neodsledovatelnou** politikou a uplatňuje se v nejranější fázi zpracování paketů v Linuxu. Pokud se podíváte na diagram výše, politiky untracked se uplatňují v řetězcích PREROUTING a OUTPUT v tabulce raw, dříve než začne sledování připojení (conntrack). Když je paket povolen politikou untracked, je označen tak, aby se zrušilo sledování připojení pro tento paket. To znamená:
- Politika untracked se uplatňuje na každý paket. Neexistuje pojem připojení (nebo toku). Absence připojení má několik důležitých důsledků:
- Pokud chcete povolit jak příchozí, tak odchozí provoz, potřebujete pravidlo jak pro příchozí, tak pro odchozí (protože Calico obvykle používá conntrack k označení odpovědního provozu jako povoleného).
- Politika untracked nefunguje pro Kubernetes workloads (pody), protože v tomto případě neexistuje způsob, jak sledovat odchozí připojení z podu.
- NAT nefunguje správně s neodsledovatelnými pakety (protože jádro uchovává mapování NAT v conntracku).
- Při průchodu pravidlem „povolit vše“ v untracked politice budou všechny pakety označeny jako neodsledovatelné. To bývá téměř vždy to, co nepotřebujete, takže je důležité být velmi selektivní vůči paketům povoleným untracked politikami (a umožnit většině provozu procházet standardními sledovanými politikami).
- Nezaznamenané politiky se uplatňují na začátku zpracování paketů. Je velmi důležité to mít na paměti při vytváření politik Calico. Můžete mít politiku pro pod s order:1 a nezaznamenanou politiku s order:1000. To však nebude mít význam. Nezaznamenaná politika bude uplatněna před politikou pro pod. Nezaznamenané politiky dodržují pořadí vykonávání pouze mezi sebou.
Jelikož jedním z cílů politiky doNotTrack je vynucení politiky na samém počátku zpracování paketů Linuxu, Calico vyžaduje uvedení možnosti applyOnForward při použití doNotTrack. Při pohledu na diagram zpracování paketů si povšimněte, že politika nezaznamenaná (5) se uplatňuje před jakýmikoliv rozhodnutími o routování. Provoz může být směrován k hostitelskému procesu, nebo může být přesměrován na pod nebo jiný uzel.
Závěry
Prozkoumali jsme různé možnosti politik (Host endpoint, ApplyOnForward, preDNAT a Nezaznamenané) v Calico a jak se uplatňují na cestě zpracování paketů. Porozumění jejich podstatě pomáhá při vyvíjení efektivních a bezpečných politik. S pomocí Calico můžete použít globální síťovou politiku, která se vztahuje na štítek (skupinu uzlů a podů) a uplatňovat politiky s různými parametry. To umožňuje specialistům na bezpečnost a návrh sítí pohodlně chránit okamžitě „vše“ (typy koncových bodů) pomocí jednotného jazyka politik s politikami Calico.
Poděkování: Rád bych poděkoval a za jejich přehled a cenné informace.
Zdroj: habr.com
