Förståelse för tillämpningar av nätverkspolicys med Calico

Calico-nätverkspluginet erbjuder ett omfattande utbud av nätverkspolicyer med en enhetlig syntax för att skydda värdar på hårdvara, virtuella maskiner och poddar. Dessa policyer kan tillämpas inom namespaces eller vara globala nätverkspolicyer som gäller för värdpunkt (för att skydda applikationer som körs direkt på värden — en värd kan vara en fysisk server eller en virtuell maskin) eller för arbetslastpunkt (för att skydda applikationer som körs i containrar eller virtuella maskiner som är värdade på värden). Calico-policyer möjliggör säkerhetsåtgärder för olika vägpunktspaket genom alternativ som preDNAT, unraracked och applyOnForward. Att förstå hur dessa alternativ fungerar kan bidra till att förbättra säkerheten och prestandan hos systemet som helhet. I den här artikeln förklaras kärnan i dessa Calico-policyalternativ (preDNAT, unraracked och applyOnForward) som tillämpas på värdändpunkter, med fokus på vad som händer i paketbehandlingsvägarna (iptables-kedjor).

Denna artikel förutsätter att du har en grundläggande förståelse för nätverkspolicyer i Kubernetes och Calico. Om du inte har det rekommenderar vi att du testar grundläggande nätverkspolicytutorial och tutorial för värdskydd med Calico innan du läser denna artikel. Vi förutsätter också att du har en grundläggande förståelse av iptables Linux.

Calico global nätverkspolicy möjliggör för dig att tillämpa en uppsättning åtkomstregler baserat på etiketter (till grupper av värdar och arbetsbelastningar/poddar). Detta är mycket användbart om du använder olika system tillsammans — virtuella maskiner, system direkt på hårdvara eller Kubernetes-infrastruktur. Dessutom kan du skydda din kluster (noder) med en uppsättning deklarativa policys och tillämpa nätverkspolicys på inkommande trafik (till exempel genom NodePorts-tjänster eller externa IP-adresser).

På en grundläggande nivå, när Calico kopplar en pod till nätverket (se diagrammet nedan), kopplar det den till värden med hjälp av en virtuell Ethernet-gränssnitt (veth). Trafik som skickas av podden kommer till värden från det virtuella gränssnittet och hanteras på samma sätt som om den kom från ett fysiskt nätverksgränssnitt. Som standard kallar Calico dessa gränssnitt caliXXX. Eftersom trafiken kommer genom det virtuella gränssnittet går den igenom iptables, som om podden var en hop bort. Därför, när trafik kommer/från podden, vidarebefordras den sett från värden.

På Kubernetes-noden där Calico körs kan du koppla det virtuella gränssnittet (veth) till arbetsbelastningen på följande sätt. I exemplet nedan kan du se att veth#10 (calic1cbf1ca0f8) är kopplad till cnx-manager-* i calico-monitoring-namnsrymden.

[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
...

Med tanke på att Calico skapar veth-gränssnitt för varje arbetsbelastning, hur tillämpar det policyer? För detta skapar Calico hooks i olika kedjor för paketbehandling med hjälp av iptables.

I diagrammet nedan visas kedjorna som är involverade i paketbehandling i iptables (eller netfilter-systemet). När ett paket kommer in genom nätverksgränssnittet passerar det först genom kedjan PREROUTING. Beslut fattas om routing, och på grundval av detta går paketet antingen genom INPUT (dirigerat till värdens processer), eller genom FORWARD (dirigerat till podden eller en annan nod i nätverket). Från den lokala processen passerar paketet genom kedjan OUTPUT, och sedan POSTROUTING innan det skickas via kabeln.

Observera att podden även är ett externt objekt (kopplat till veth) sett ur iptables paketbehandling. Låt oss sammanfatta:

• Vidarebefordrad trafik (nat, routad eller in/ut från pod) passerar genom kedjorna PREROUTING — FORWARD — POSTROUTING.
• Trafik till den lokala värdprocessen passerar genom kedjan PREROUTING — INPUT.
• Trafik från den lokala värdprocessen passerar genom kedjan OUTPUT — POSTROUTING.

Calico erbjuder alternativ för policyer som gör det möjligt att tillämpa policyer på alla kedjor. Med detta i åtanke, låt oss gå igenom de olika inställningsalternativen som är tillgängliga i Calico. Siffrorna i listan över alternativ nedan motsvarar siffrorna på diagrammet ovan.

1. Workload endpoint (pod) policy
2. Host endpoint policy
3. ApplyOnForward-alternativet
4. PreDNAT-policy
5. Untracked-policy

Låt oss börja med att undersöka hur policyer tillämpas på workload endpoints (Kubernetes-pods eller OpenStack-VM:ar) och sedan granska policyalternativen för host endpoints.

Workload Endpoints

Workload Endpoint Policy (1)

Detta är ett alternativ för att skydda dina Kubernetes-pods. Calico stödjer arbete med Kubernetes NetworkPolicy, men erbjuder också ytterligare policyer — Calico NetworkPolicy och GlobalNetworkPolicy. Calico skapar en kedja för varje pod (workload) och hookar in i kedjorna INPUT och OUTPUT för workload till filtertabellen i kedjan FORWARD.

Host Endpoints

Host Endpoint Policy (2)

Utöver CNI (container network interface) erbjuder Calicos policyer möjlighet att skydda själva värden. I Calico kan du skapa en host endpoint genom att ange en kombination av värdgränssnitt och, om så önskas, portnummer. Tillämpning av policyer för denna enhet uppnås med hjälp av filtertabeller i kedjorna INPUT och OUTPUT. Som visas i diagrammet, (2) tillämpas de på lokala processer på noden/värden. Det vill säga, om du har skapat en policy som tillämpas på en host endpoint, påverkar den inte trafiken till/från dina pods. Men den säkerställer en enhetlig gränssnitt/syntax för att blockera trafik för din värd och pods med hjälp av Calicos policyer. Detta gör hanteringen av policyer för heterogena nätverk betydligt enklare. Att konfigurera host endpoint-policyer för att stärka skyddet av klustret är ytterligare en viktig användning.

ApplyOnForward Policy (3)

ApplyOnForward-alternativet finns i Calico global network policy för att möjliggöra tillämpning av policyer på all trafik som passerar genom host endpoint, inklusive trafik som kommer att vidarebefordras av värden. Denna trafik inkluderar omdirigerad trafik till en lokal pod eller någon annanstans i nätverket. Calico kräver att detta alternativ aktiveras för policyer som använder PreDNAT och untracked, se följande avsnitt. Dessutom kan ApplyOnForward användas för att spåra värdtrafik i fall med virtuella routrar eller mjukvarunat.

Observera att om du behöver tillämpa en och samma nätverkspolicy för både värdprocesser och poddar, behöver du inte använda alternativet ApplyOnForward. Det räcker att skapa en etikett för de nödvändiga hostendpoint och workload endpoint (pod). Calico är tillräckligt intelligent för att tillämpa policyn baserat på etiketter, oavsett typ av endpoint (hostendpoint eller workload).

PreDNAT Policy (4)

I Kubernetes kan portar för service-entiteten exponeras utåt med hjälp av alternativet NodePorts eller, valfritt (vid användning av Calico), genom deklarationer via alternativ för Cluster IPs eller External IPs. Kube-proxy balanserar inkommande trafik kopplad till service till poddar av motsvarande service med hjälp av DNAT. Givet detta, hur kan du tillämpa policys för trafiken som kommer genom NodePorts? För att dessa policies ska tillämpas innan trafiken hanteras av DNAT (som representerar en koppling mellan värd:port och motsvarande service), tillhandahåller Calico ett parameter för globalNetworkPolicy som kallas "preDNAT: true".

När pre-DNAT är aktiverat, implementeras dessa policies i (4) på diagrammet – i mangle-kedjetabellen PREROUTING – direkt före DNAT. Den vanliga ordningen av policies (order) följs inte här, eftersom tillämpningen av dessa policies sker mycket tidigare i trafikbehandlingsvägen. Dock följer preDNAT-policys ordningen för tillämpning (order) mellan sig.

När man skapar policies med pre-DNAT är det viktigt att vara uppmärksam på trafiken som du vill bearbeta, och att tillåta majoriteten att avvisas. Trafik som märks som 'allow' i pre-DNAT-policyn kommer inte längre att kontrolleras av hostendpoint-policyn, medan trafik som misslyckas med att passera pre-DNAT-policyn fortsätter att gå genom de övriga kedjorna.
Calico har gjort det obligatoriskt att aktivera alternativet applyOnForward vid användning av preDNAT, eftersom destinationspunkten för trafiken ännu inte har valts. Trafiken kan riktas till en värdprocess, eller den kan omdirigeras till en pod eller till en annan nod.

Untracked Policy (5)

Nätverk och applikationer kan ha stora skillnader i beteende. I vissa extrema fall kan applikationer generera ett stort antal kortvariga anslutningar. Detta kan leda till minnesbrist hos conntrack (den grundläggande komponenten i Linux nätverksstack). Traditionellt behöver du manuellt konfigurera eller inaktivera conntrack eller skriva iptables-regler för att kringgå conntrack för att köra applikationer av denna typ i Linux. Untracked policy i Calico är ett enklare och mer effektivt alternativ om du vill hantera anslutningar så snabbt som möjligt. Till exempel, om du använder en massiv memcache eller som ett extra skydd mot DDOS.

Läs detta blogginlägg (eller vår översättning) för mer information, inklusive prestandatest vid användning av untracked policy.

När du ställer in alternativet "doNotTrack: true" i Calico globalNetworkPolicy blir den en **oövervakad** policy och tillämpas i ett tidigt skede av Linux paketbehandlingskedja. Om du tittar på diagrammet ovan tillämpas untracked policies i PREROUTING och OUTPUT kedjorna i raw-tabellen, innan anslutningsspårning (conntrack) aktiveras. När ett paket tillåts av untracked policyn, märks det för att inaktivera anslutningsspårning för detta paket. Detta innebär:

• Untracked policyn tillämpas på varje paket. Det finns inget begrepp om en anslutning (eller flöde). Avsaknaden av anslutningar medför flera viktiga konsekvenser:
• Om du vill tillåta både begärningstrafik och svarsanslutningar behöver du en regel för både inkommande och utgående (eftersom Calico vanligtvis använder conntrack för att märka svarstrafik som tillåten).
• Untracked policyn fungerar inte för Kubernetes arbetsbelastningar (poddar), eftersom det i detta fall inte finns något sätt att spåra utgående anslutningar från en podd.
• NAT fungerar felaktigt med oövervakade paket (eftersom kärnan lagrar NAT-kopplingar i conntrack).
• Vid passage genom regeln "tillåt allt" i untracked-policyn kommer alla paket att märkas som oövervakade. Detta är nästan alltid inte vad du behöver, så det är viktigt att vara mycket selektiv med de paket som tillåts av untracked-policys (och låta större delen av trafiken gå igenom vanliga övervakade policies).
• Oövervakade policyer tillämpas i början av paketbearbetningskonvejerbelaget. Det är mycket viktigt att förstå detta när man skapar Calico-policyer. Du kan ha en policy för en pod med order:1 och en oövervakad policy med order:1000. Detta spelar ingen roll. Den oövervakade policyn kommer att tillämpas innan pod-policyn. Oövervakade policies följer endast exekveringsordning mellan sig själva.

Eftersom ett av målen med doNotTrack-policyn är att tvinga tillämpningen av policyn tidigt i Linux paketbearbetningskonvejerbelaget, gör Calico det obligatoriskt att ange alternativet applyOnForward när doNotTrack används. Titta på paketbearbetningsdiagrammet, notera att den oövervakade policyn (5) tillämpas innan några routingbeslut fattas. Trafik kan riktas till värdprocessen, eller så kan den omdirigeras till en pod eller en annan nod.

Sammanfattning

Vi har granskat olika policyalternativ (Host endpoint, ApplyOnForward, preDNAT och Oövervakad) i Calico och hur de tillämpas på vägen för paketbearbetning. Att förstå deras essens hjälper till att utveckla effektiva och säkra policys. Med Calico kan du använda globala nätverkspolicyer som tillämpas på etiketter (grupper av noder och pods) och tillämpa policys med olika alternativ. Detta gör det möjligt för säkerhets- och nätverksdesignspecialister att enkelt skydda allt (typer av endpoints) med ett enhetligt språk för policys med Calico-policys.

Tacksamhet: Jag vill tacka Shaun Crampton och Alex Pollett för deras översyn och värdefull information.

Källa: habr.com