Calico nätverksplugin tillhandahåller ett brett utbud av nätverkspolicyer med en enhetlig syntax för att skydda hårdvaruvärdar, virtuella maskiner och pods. Dessa policyer kan tillämpas inom ett namnområde eller vara globala nätverkspolicyer som gäller (för att skydda applikationer som körs direkt på värden - värden kan vara en server eller en virtuell maskin) eller (för att skydda applikationer som körs i behållare eller värdbaserade virtuella maskiner). Calico-policyer låter dig tillämpa säkerhetsåtgärder på olika punkter i ett pakets väg med alternativ som preDNAT, unraracked och applicationOnForward. Att förstå hur dessa alternativ fungerar kan bidra till att förbättra säkerheten och prestandan för ditt övergripande system. Den här artikeln förklarar essensen av dessa Calico-policyalternativ (preDNAT, unraracked och applicationOnForward) som tillämpas på värdslutpunkter, med betoning på vad som händer i paketbearbetningsvägar (iptabels-kedjor).
Den här artikeln förutsätter att du har en grundläggande förståelse för hur Kubernetes och Calicos nätverkspolicyer fungerar. Om inte, rekommenderar vi att du provar det и använder Calico innan du läser den här artikeln. Vi förväntar oss även att du har en grundläggande förståelse för arbetet i linux.
Kalikå låter dig tillämpa en uppsättning åtkomstregler efter etiketter (på grupper av värdar och arbetsbelastningar/pods). Detta är mycket användbart om du använder heterogena system tillsammans - virtuella maskiner, ett system direkt på hårdvara eller en kubernetes-infrastruktur. Dessutom kan du skydda ditt kluster (noder) med hjälp av en uppsättning deklarativa principer och tillämpa nätverkspolicyer på inkommande trafik (till exempel genom tjänsten NodePorts eller External IPs).
På en grundläggande nivå, när Calico ansluter en pod till nätverket (se diagram nedan), ansluter den den till värden med hjälp av ett virtuellt Ethernet-gränssnitt (veth). Trafiken som skickas av podden kommer till värden från detta virtuella gränssnitt och bearbetas på samma sätt som om den kom från ett fysiskt nätverksgränssnitt. Som standard döper Calico dessa gränssnitt till caliXXX. Eftersom trafiken kommer genom det virtuella gränssnittet går den genom iptables som om podden var ett hopp bort. Därför, när trafik kommer till/från en pod, vidarebefordras den från värdens synvinkel.
På en Kubernetes-nod som kör Calico kan du mappa ett virtuellt gränssnitt (veth) till en arbetsbelastning enligt följande. I exemplet nedan kan du se att veth#10 (calic1cbf1ca0f8) är ansluten till cnx-manager-* i calico-monitoring-namnområdet.
[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
...
Med tanke på att Calico skapar ett veth-gränssnitt för varje arbetsbelastning, hur upprätthåller det policyer? För att göra detta skapar Calico krokar i olika kedjor av paketbearbetningsvägen med hjälp av iptables.
Diagrammet nedan visar kedjorna som är involverade i paketbearbetning i iptables (eller undersystemet netfilter). När ett paket kommer via ett nätverksgränssnitt går det först genom PREROUTING-kedjan. Ett routingbeslut fattas sedan och baserat på detta passerar paketet genom antingen INPUT (riktat till värdprocesser) eller FORWARD (riktat till en pod eller annan nod på nätverket). Från den lokala processen går paketet genom OUTPUT- och sedan POSTROUTING-kedjan innan det skickas ner i kabeln.
Observera att podden också är en extern enhet (ansluten till veth) när det gäller iptables-bearbetning. Låt oss sammanfatta:
- Vidarebefordrad trafik (nat, dirigerad eller till/från en pod) passerar genom kedjorna PREROUTING - FORWARD - POSTROUTING.
- Trafiken till den lokala värdprocessen går genom kedjan PREROUTING - INPUT.
- Trafik från den lokala värdprocessen går genom OUTPUT - POSTROUTING-kedjan.
Calico tillhandahåller policyalternativ som gör att du kan tillämpa policyer i alla kedjor. Med det i åtanke, låt oss titta på de olika policykonfigurationsalternativen som finns tillgängliga i Calico. Siffrorna i listan med alternativ nedan motsvarar siffrorna i diagrammet ovan.
- Arbetsbelastningsändpunktspolicy (pod).
- Värdens slutpunktspolicy
- Alternativet ApplyOnForward
- PreDNAT-policy
- Ospårad policy
Låt oss börja med att titta på hur policyer tillämpas på arbetsbelastningsslutpunkter (Kubernetes-poddar eller OpenStack VMs), och titta sedan på policyalternativen för värdändpunkter.
Arbetsbelastningsslutpunkter
Arbetsbelastningsslutpunktspolicy (1)
Detta är ett alternativ för att skydda dina kubernetes-pods. Calico stöder arbete med Kubernetes NetworkPolicy, men det tillhandahåller också ytterligare policyer - Calico NetworkPolicy och GlobalNetworkPolicy. Calico skapar en kedja för varje pod (arbetsbelastning) och kopplar in INPUT- och OUTPUT-kedjorna för arbetsbelastningen till filtertabellen i FORWARD-kedjan.
Värdslutpunkter
Värdens slutpunktspolicy (2)
Förutom CNI (container network interface) ger Calico-policyer möjligheten att skydda värden själv. I Calico kan du skapa en värdslutpunkt genom att ange en kombination av värdgränssnittet och vid behov portnummer. Policytillämpning för denna enhet uppnås med hjälp av en filtertabell i INPUT- och OUTPUT-kedjorna. Som du kan se från diagrammet, (2) gäller de lokala processer på noden/värden. Det vill säga, om du skapar en policy som gäller för värdändpunkten kommer det inte att påverka trafiken som går till/från dina poddar. Men det ger ett enda gränssnitt/syntax för att blockera trafik för din värd och poddar med hjälp av Calico-policyer. Detta förenklar avsevärt processen att hantera policyer för ett heterogent nätverk. Att konfigurera värdslutpunktspolicyer för att förbättra klustersäkerheten är ett annat viktigt användningsfall.
ApplyOnForward Policy (3)
Alternativet ApplyOnForward är tillgängligt i Calicos globala nätverkspolicy för att tillåta policyer att tillämpas på all trafik som passerar genom värdslutpunkten, inklusive trafik som kommer att vidarebefordras av värden. Detta inkluderar trafik som vidarebefordras till den lokala podden eller någon annanstans på nätverket. Calico kräver att den här inställningen är aktiverad för policyer som använder PreDNAT och ospårad, se följande avsnitt. Dessutom kan ApplyOnForward användas för att övervaka värdtrafiken i de fall en virtuell router eller mjukvara NAT används.
Observera att om du behöver tillämpa samma nätverkspolicy för både värdprocesser och pods, behöver du inte använda alternativet ApplyOnForward. Allt du behöver göra är att skapa en etikett för den nödvändiga värdändpunkten och arbetsbelastningsändpunkten (pod). Calico är smart nog att genomdriva policy baserad på etiketter, oavsett slutpunktstyp (värdpunkt eller arbetsbelastning).
PreDNAT-policy (4)
I Kubernetes kan tjänstentitetsportar exponeras externt med alternativet NodePorts eller, valfritt (när du använder Calico), genom att annonsera dem med alternativen Cluster IPs eller External IPs. Kube-proxy balanserar inkommande trafik som är bunden till en tjänst till poddarna för motsvarande tjänst med hjälp av DNAT. Med tanke på detta, hur upprätthåller du policyer för trafik som kommer genom NodePorts? För att säkerställa att dessa policyer tillämpas innan trafiken bearbetas av DNAT (som är en mappning mellan värd:port och motsvarande tjänst), tillhandahåller Calico en parameter för globalNetworkPolicy som kallas "preDNAT: true".
När pre-DNAT är aktiverat, implementeras dessa principer i (4) i diagrammet - i mangletabellen för PREROUTING-kedjan - omedelbart före DNAT. Den vanliga ordningen för policyer följs inte här, eftersom tillämpningen av dessa policyer sker mycket tidigare i trafikbearbetningsvägen. PreDNAT-policyer respekterar dock tillämpningsordningen sinsemellan.
När du skapar policyer med pre-DNAT är det viktigt att vara försiktig med den trafik du vill bearbeta och låta majoriteten avvisas. Trafik markerad som 'tillåt' i pre-DNAT-policyn kommer inte längre att kontrolleras av värdpunktspolicyn, medan trafik som inte uppfyller pre-DNAT-policyn kommer att fortsätta genom de återstående kedjorna.
Calico har gjort det obligatoriskt att aktivera alternativet applicationOnForward när du använder preDNAT, eftersom destinationen för trafiken per definition inte har valts ut ännu. Trafik kan dirigeras till värdprocessen, eller så kan den vidarebefordras till en pod eller en annan nod.
Ospårad policy (5)
Nätverk och applikationer kan ha stora skillnader i beteende. I vissa extrema fall kan applikationer generera många kortlivade anslutningar. Detta kan få conntrack (en kärnkomponent i Linux-nätverksstacken) att ta slut på minne. Traditionellt, för att köra dessa typer av applikationer på Linux, måste du manuellt konfigurera eller inaktivera conntrack, eller skriva iptables-regler för att kringgå conntrack. Ospårad policy i Calico är ett enklare och mer effektivt alternativ om du vill bearbeta anslutningar så snabbt som möjligt. Till exempel om du använder massiv eller som ytterligare skyddsåtgärd mot .
Läs detta (eller ) för mer information, inklusive prestandatester med ospårad policy.
När du ställer in alternativet "doNotTrack: true" i Calico globalNetworkPolicy, blir det en **ospårad** policy och tillämpas mycket tidigt i Linux-paketbearbetningspipelinen. Om man tittar på diagrammet ovan, tillämpas ospårade policyer i PREROUTING- och OUTPUT-kedjorna i råtabellen innan anslutningsspårning (conntrack) startas. När ett paket tillåts av den ospårade policyn är det markerat för att inaktivera anslutningsspårning för det paketet. Det betyder:
- Den ospårade policyn tillämpas per paket. Det finns inget begrepp om anslutning (eller flöde). Brist på anslutningar har flera viktiga konsekvenser:
- Om du vill tillåta både begäran och svarstrafik behöver du en regel för både inkommande och utgående (eftersom Calico vanligtvis använder conntrack för att markera svarstrafik som tillåten).
- Den ospårade policyn fungerar inte för Kubernetes-arbetsbelastningar (pods), eftersom det i det här fallet inte finns något sätt att spåra den utgående anslutningen från podden.
- NAT fungerar inte korrekt med ospårade paket (eftersom kärnan lagrar NAT-mappningen i conntrack).
- När du går igenom regeln "tillåt alla" i den ospårade policyn kommer alla paket att markeras som ospårade. Detta är nästan alltid inte vad du vill ha, så det är viktigt att vara mycket selektiv när det gäller de paket som tillåts av ospårade policyer (och tillåta den mesta trafiken att gå igenom normala spårade policyer).
- Ospårade policyer tillämpas i början av paketbearbetningspipelinen. Detta är mycket viktigt att förstå när du skapar Calico-policyer. Du kan ha en podpolicy med order:1 och en ospårad policy med order:1000. Det spelar ingen roll. Den ospårade policyn kommer att tillämpas före policyn för podden. Ospårade policyer respekterar endast exekveringsorder sinsemellan.
Eftersom ett av syftena med doNotTrack-policyn är att upprätthålla policyn mycket tidigt i Linux-paketbearbetningspipelinen, gör Calico det obligatoriskt att ange alternativet applicationOnForward när du använder doNotTrack. Med hänvisning till diagrammet för paketbearbetning, notera att policyn för untracked(5) tillämpas före eventuella routingbeslut. Trafik kan dirigeras till värdprocessen, eller så kan den vidarebefordras till en pod eller en annan nod.
Resultat av
Vi tittade på de olika policyalternativen (Host endpoint, ApplyOnForward, preDNAT och Untracked) i Calico och hur de tillämpas längs paketbearbetningsvägen. Att förstå hur de fungerar hjälper till att utveckla effektiva och säkra policyer. Med Calico kan du använda en global nätverkspolicy som gäller för en etikett (en grupp av noder och pods) och tillämpa policyer med olika parametrar. Detta gör att säkerhets- och nätverksdesigner kan bekvämt skydda "allt" (slutpunktstyper) på en gång med ett enda policyspråk med Calico-policyer.
Tack: Jag skulle vilja tacka и för deras granskning och värdefull information.
Källa: will.com