🥇Forstå muligheder for netværkspolitik med Calico

Calico-netværksplugin'et giver en bred vifte af netværkspolitikker med en samlet syntaks til at beskytte hardwareværter, virtuelle maskiner og pods. Disse politikker kan anvendes inden for et navneområde eller være globale netværkspolitikker, der gælder for værtens slutpunkt (for at beskytte applikationer, der kører direkte på værten - værten kan være en server eller en virtuel maskine) eller arbejdsbelastning endpoint (for at beskytte applikationer, der kører i containere eller hostede virtuelle maskiner). Calico-politikker giver dig mulighed for at anvende sikkerhedsforanstaltninger på forskellige punkter i en pakkes vej ved hjælp af muligheder såsom preDNAT, unraracked og applyOnForward. At forstå, hvordan disse muligheder fungerer, kan hjælpe med at forbedre sikkerheden og ydeevnen for dit overordnede system. Denne artikel forklarer essensen af disse Calico-politikmuligheder (preDNAT, unraracked og applyOnForward) anvendt på værtsendepunkter med vægt på, hvad der sker i pakkebehandlingsstier (iptabels-kæder).

Denne artikel antager, at du har en grundlæggende forståelse af, hvordan Kubernetes- og Calico-netværkspolitikker fungerer. Hvis ikke, anbefaler vi at prøve det grundlæggende netværkspolitik tutorial и værtsbeskyttelse tutorial ved at bruge Calico, før du læser denne artikel. Vi forventer desuden, at du har en grundlæggende forståelse for arbejdet iptables i linux.

Calico global netværkspolitik giver dig mulighed for at anvende et sæt adgangsregler efter etiketter (på grupper af værter og arbejdsbelastninger/pods). Dette er meget nyttigt, hvis du bruger heterogene systemer sammen - virtuelle maskiner, et system direkte på hardware eller en kubernetes-infrastruktur. Derudover kan du beskytte din klynge (noder) ved hjælp af et sæt af deklarative politikker og anvende netværkspolitikker på indgående trafik (f.eks. gennem NodePorts eller Eksterne IPs-tjenesten).

På et grundlæggende niveau, når Calico forbinder en pod til netværket (se diagrammet nedenfor), forbinder den den til værten ved hjælp af en virtuel Ethernet-grænseflade (veth). Trafikken sendt af poden kommer til værten fra denne virtuelle grænseflade og behandles på samme måde, som hvis den kom fra en fysisk netværksgrænseflade. Som standard navngiver Calico disse grænseflader caliXXX. Da trafikken kommer gennem den virtuelle grænseflade, går den gennem iptables, som om poden var et hop væk. Derfor, når der kommer trafik til/fra en pod, videresendes den fra værtens synspunkt.

På en Kubernetes-node, der kører Calico, kan du kortlægge en virtuel grænseflade (veth) til en arbejdsbelastning som følger. I eksemplet nedenfor kan du se, at veth#10 (calic1cbf1ca0f8) er forbundet til cnx-manager-* i calico-monitoring-navnerummet.

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

I betragtning af at Calico opretter en veth-grænseflade for hver arbejdsbyrde, hvordan håndhæver den politikker? For at gøre dette opretter Calico hooks i forskellige kæder af pakkebehandlingsstien ved hjælp af iptables.

Diagrammet nedenfor viser de kæder, der er involveret i pakkebehandling i iptables (eller netfilter-undersystemet). Når en pakke ankommer gennem en netværksgrænseflade, går den først gennem PREROUTING-kæden. Der træffes derefter en routingbeslutning, og baseret på denne passerer pakken enten INPUT (dirigeret til værtsprocesser) eller FORWARD (dirigeret til en pod eller en anden node på netværket). Fra den lokale proces går pakken gennem OUTPUT- og derefter POSTROUTING-kæden, før den sendes ned i kablet.

Bemærk, at poden også er en ekstern enhed (forbundet til veth) med hensyn til iptables-behandling. Lad os opsummere:

Videresendt trafik (nat, dirigeret eller til/fra en pod) passerer gennem PREROUTING - FORWARD - POSTROUTING-kæderne.
Trafik til den lokale værtsproces passerer gennem PREROUTING - INPUT-kæden.
Trafik fra den lokale værtsproces går gennem OUTPUT - POSTROUTING-kæden.

Calico tilbyder politikmuligheder, der giver dig mulighed for at anvende politikker på tværs af alle kæder. Med det i tankerne, lad os se på de forskellige politikkonfigurationsmuligheder, der er tilgængelige i Calico. Tallene på listen over muligheder nedenfor svarer til tallene i diagrammet ovenfor.

Arbejdsbelastning endpoint (pod) politik
Værts slutpunktspolitik
ApplyOnForward mulighed
PreDNAT-politik
Usporet politik

Lad os starte med at se på, hvordan politikker anvendes på arbejdsbelastningsendepunkter (Kubernetes-pods eller OpenStack VM'er), og se derefter på politikmulighederne for værtsendepunkter.

Arbejdsbelastningsendepunkter

Arbejdsbelastning slutpunktspolitik (1)

Dette er en mulighed for at beskytte dine kubernetes pods. Calico understøtter arbejdet med Kubernetes NetworkPolicy, men det giver også yderligere politikker - Calico NetworkPolicy og GlobalNetworkPolicy. Calico opretter en kæde for hver pod (arbejdsbelastning) og tilslutter INPUT- og OUTPUT-kæderne for arbejdsbelastningen til filtertabellen i FORWARD-kæden.

Værts slutpunkter

Værts slutpunktspolitik (2)

Ud over CNI (container netværksgrænseflade) giver Calico-politikker mulighed for at beskytte værten selv. I Calico kan du oprette et værtsslutpunkt ved at angive en kombination af værtsgrænsefladen og om nødvendigt portnumre. Politikhåndhævelse for denne enhed opnås ved hjælp af en filtertabel i INPUT- og OUTPUT-kæderne. Som du kan se af diagrammet, (2) gælder de for lokale processer på noden/værten. Det vil sige, at hvis du opretter en politik, der gælder for værtens slutpunkt, vil det ikke påvirke trafikken, der går til/fra dine pods. Men det giver en enkelt grænseflade/syntaks til at blokere trafik for din vært og pods ved hjælp af Calico-politikker. Dette forenkler i høj grad processen med at styre politikker for et heterogent netværk. Konfiguration af værtens slutpunktspolitikker for at forbedre klyngesikkerheden er en anden vigtig use case.

ApplyOnForward-politik (3)

Indstillingen ApplyOnForward er tilgængelig i Calicos globale netværkspolitik for at tillade, at politikker anvendes på al trafik, der passerer gennem værtens slutpunkt, inklusive trafik, der videresendes af værten. Dette inkluderer trafik videresendt til den lokale pod eller andre steder på netværket. Calico kræver, at denne indstilling er aktiveret for politikker, der bruger PreDNAT og usporet, se følgende afsnit. Derudover kan ApplyOnForward bruges til at overvåge værtstrafik i tilfælde, hvor en virtuel router eller software NAT bruges.

Bemærk, at hvis du skal anvende den samme netværkspolitik på både værtsprocesser og pods, så behøver du ikke bruge ApplyOnForward-indstillingen. Alt du skal gøre er at oprette en etiket til det påkrævede hostendpoint og workload endpoint (pod). Calico er smart nok til at håndhæve politik baseret på etiketter, uanset slutpunktstypen (værtsendepunkt eller arbejdsbyrde).

PreDNAT-politik (4)

I Kubernetes kan serviceentitetsporte eksponeres eksternt ved hjælp af NodePorts-indstillingen eller eventuelt (når du bruger Calico), ved at annoncere for dem ved hjælp af Cluster-IP'er eller Eksterne IP-indstillinger. Kube-proxy balancerer indgående trafik bundet til en tjeneste til pods af den tilsvarende tjeneste ved hjælp af DNAT. I betragtning af dette, hvordan håndhæver du politikker for trafik, der kommer gennem NodePorts? For at sikre, at disse politikker anvendes, før trafikken behandles af DNAT (som er en mapping mellem host:port og tilsvarende tjeneste), leverer Calico en parameter for globalNetworkPolicy kaldet "preDNAT: true".

Når præ-DNAT er aktiveret, implementeres disse politikker ved (4) i diagrammet - i mangletabellen i PREROUTING-kæden - umiddelbart før DNAT. Den sædvanlige rækkefølge af politikker følges ikke her, da anvendelsen af disse politikker sker meget tidligere i trafikbehandlingsstien. Imidlertid respekterer preDNAT-politikker rækkefølgen af anvendelse indbyrdes.

Når du opretter politikker med pre-DNAT, er det vigtigt at være forsigtig med den trafik, du ønsker at behandle, og lade flertallet blive afvist. Trafik markeret som 'tillad' i præ-DNAT-politikken vil ikke længere blive kontrolleret af hostendpoint-politikken, mens trafik, der ikke overholder præ-DNAT-politikken, vil fortsætte gennem de resterende kæder.
Calico har gjort det obligatorisk at aktivere funktionen applyOnForward ved brug af preDNAT, da destinationen for trafikken pr. definition endnu ikke er valgt. Trafik kan dirigeres til værtsprocessen, eller den kan videresendes til en pod eller en anden node.

Ikke-sporet politik (5)

Netværk og applikationer kan have store forskelle i adfærd. I nogle ekstreme tilfælde kan applikationer generere mange kortlivede forbindelser. Dette kan forårsage, at conntrack (en kernekomponent i Linux-netværksstakken) løber tør for hukommelse. Traditionelt, for at køre disse typer applikationer på Linux, skulle du manuelt konfigurere eller deaktivere conntrack eller skrive iptables-regler for at omgå conntrack. Usporet politik i Calico er en enklere og mere effektiv mulighed, hvis du vil behandle forbindelser så hurtigt som muligt. For eksempel hvis du bruger massive memcache eller som yderligere beskyttelse mod DDOS.

Læs dette blogindlæg (eller vores oversættelse) for at få flere oplysninger, herunder præstationstest, der bruger usporet politik.

Når du indstiller "doNotTrack: true"-indstillingen i Calico globalNetworkPolicy, bliver den en **usporet** politik og anvendes meget tidligt i Linux-pakkebehandlingspipelinen. Ser man på diagrammet ovenfor, anvendes ikke-sporede politikker i PREROUTING- og OUTPUT-kæderne i råtabellen, før forbindelsessporing (conntrack) startes. Når en pakke er tilladt af den usporede politik, er den markeret for at deaktivere forbindelsessporing for den pågældende pakke. Det betyder:

Den usporede politik anvendes på pakkebasis. Der er intet begreb om forbindelse (eller flow). Mangel på forbindelser har flere vigtige konsekvenser:
Hvis du vil tillade både anmodnings- og svartrafik, skal du bruge en regel for både indgående og udgående (da Calico typisk bruger conntrack til at markere svartrafik som tilladt).
Den usporede politik virker ikke for Kubernetes-arbejdsbelastninger (pods), fordi der i dette tilfælde ikke er nogen måde at spore den udgående forbindelse fra poden.
NAT fungerer ikke korrekt med usporede pakker (da kernen gemmer NAT-tilknytningen i conntrack).
Når du passerer gennem reglen "tillad alle" i den usporede politik, vil alle pakker blive markeret som usporede. Dette er næsten altid ikke, hvad du ønsker, så det er vigtigt at være meget selektiv med hensyn til de pakker, der tillades af usporede politikker (og tillade det meste trafik at gå gennem normale sporede politikker).
Ikke-sporede politikker anvendes helt i begyndelsen af pakkebehandlingspipelinen. Dette er meget vigtigt at forstå, når du opretter Calico-politikker. Du kan have en pod-politik med ordre:1 og en usporet politik med ordre:1000. Det gør ikke noget. Den usporede politik vil blive anvendt før politikken for poden. Ikke-sporede politikker respekterer kun udførelsesordre indbyrdes.

Fordi et af formålene med doNotTrack-politikken er at håndhæve politikken meget tidligt i Linux-pakkebehandlingspipelinen, gør Calico det obligatorisk at specificere applicationOnForward-indstillingen, når du bruger doNotTrack. Med henvisning til pakkebehandlingsdiagrammet skal du bemærke, at den usporede(5)-politik anvendes før eventuelle routingbeslutninger. Trafik kan dirigeres til værtsprocessen, eller den kan videresendes til en pod eller en anden node.

Resultaterne af

Vi så på de forskellige politikmuligheder (Host-endepunkt, ApplyOnForward, preDNAT og Untracked) i Calico, og hvordan de anvendes langs pakkebehandlingsstien. At forstå, hvordan de fungerer, hjælper med at udvikle effektive og sikre politikker. Med Calico kan du bruge en global netværkspolitik, der gælder for en etiket (en gruppe af noder og pods) og anvende politikker med forskellige parametre. Dette giver fagfolk inden for sikkerhed og netværksdesign mulighed for bekvemt at beskytte "alt" (slutpunkttyper) på én gang ved hjælp af et enkelt politiksprog med Calico-politikker.

Anerkendelse: Jeg vil gerne takke Sean Crampton и Alexa Pollitta for deres gennemgang og værdifulde oplysninger.

Kilde: www.habr.com

Forstå muligheder for håndhævelse af netværkspolitikker med Calico