Calico-netværkspluginet leverer et bredt udvalg af netværkspolitikker med en ensartet syntaks til beskyttelse af værter på hardware, virtuelle maskiner og pods. Disse politikker kan anvendes inden for et namespace eller være globale netværkspolitikker, der gælder for (til beskyttelse af applikationer, der kører direkte på værten — værten kan være en server eller en virtuel maskine) eller til (til beskyttelse af applikationer, der kører i containere eller virtuelle maskiner, der er hostet på værten). Calico-politikker giver mulighed for at anvende sikkerhedsforanstaltninger for forskellige pakkeruter ved hjælp af parametre som preDNAT, unraracked og applyOnForward. At forstå, hvordan disse muligheder fungerer, kan hjælpe med at forbedre sikkerheden og systemets generelle ydeevne. Denne artikel forklarer essensen af disse Calico-politikparametre (preDNAT, unraracked og applyOnForward), anvendt på host endpoints, med fokus på, hvad der sker i pakkehåndteringsvejene (iptables-kæder).
Denne artikel forudsætter, at du har en grundlæggende forståelse af, hvordan netværkspolitikker i Kubernetes og Calico fungerer. Hvis ikke, anbefaler vi, at du prøver og ved hjælp af Calico, før du læser denne artikel. Vi forventer også, at du har en grundlæggende forståelse for i Linux.
Calico giver dig mulighed for at anvende et sæt adgangsregler baseret på labels (til grupper af værter og workloads/pods). Dette er meget nyttigt, hvis du bruger forskellige systemer — virtuelle maskiner, systemer direkte på hardware eller Kubernetes-infrastruktur. Derudover kan du beskytte dit cluster (noder) med et sæt deklarative politikker og anvende netværkspolitikker på indkommende trafik (for eksempel gennem NodePorts-service eller eksterne IP-adresser).
På et fundamentalt niveau, når Calico forbinder en pod til netværket (se diagrammet nedenfor), forbinder det den til værten via et virtuelt Ethernet-interface (veth). Trafik sendt fra pod'en ankommer til værten fra dette virtuelle interface og behandles på samme måde, som hvis det kom fra et fysisk netværksinterface. Som standard kalder Calico disse interfaces caliXXX. Da trafikken kommer gennem det virtuelle interface, passerer den gennem iptables, som om pod'en var kun én hop væk. Derfor, når trafikken kommer fra/til pod'en, videresendes den fra værts perspektiv.
På Kubernetes-noden, hvor Calico kører, kan du matche det virtuelle interface (veth) med workload'en som følger. I det nedenfor viste eksempel kan du se, at veth#10 (calic1cbf1ca0f8) er forbundet til cnx-manager- * i 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
... 
Givet at Calico skaber et veth-interface for hver workload, hvordan anvender det politikker? Til dette skaber Calico hooks i forskellige kæder i pakkehåndteringsvejen ved hjælp af iptables.
I diagrammet nedenfor vises de kæder, der er involveret i pakkehåndtering i iptables (eller netfilter-subsystemet). Når en pakke ankommer gennem netværksinterfacet, passerer den først gennem kæden PREROUTING. Derefter træffes en routingbeslutning, og på baggrund af dette passerer pakken enten gennem INPUT (rettet mod værtsprocesserne) eller gennem FORWARD (rettet mod pod'en eller en anden node i netværket). Fra den lokale proces passerer pakken gennem kæden OUTPUT, og derefter POSTROUTING før den sendes ud.
Bemærk, at pod'en også er et eksternt objekt (forbundet til veth) med hensyn til behandling af iptables. Lad os opsummere:
- Videresendt trafik (nat, routet eller til/fra pod) passerer gennem kæderne PREROUTING - FORWARD - POSTROUTING.
- Trafik til lokal værtsproces passerer gennem kæden PREROUTING - INPUT.
- Trafik fra lokal værtsproces passerer gennem kæden OUTPUT - POSTROUTING.
Calico tilbyder muligheder for politikker, hvorved man kan anvende politikker for alle kæder. Med dette in mente, lad os se på de forskellige konfigurationsmuligheder for politikker, der er tilgængelige i Calico. Tallene i listen nedenfor svarer til numrene på diagrammet ovenfor.
- Workload-endpoint (pod) politik
- Host endpoint politik
- Mulighed for ApplyOnForward
- PreDNAT politik
- Untracked politik
Lad os begynde med at se på, hvordan politikker anvendes på workload endpoints (Kubernetes pods eller OpenStack VM'er), og derefter se nærmere på politikmulighederne for host endpoints.
Workload Endpoints
Workload Endpoint Politik (1)
Dette er en mulighed for at beskytte dine Kubernetes pods. Calico understøtter arbejdet med Kubernetes NetworkPolicy, men det tilbyder også yderligere politikker — Calico NetworkPolicy og GlobalNetworkPolicy. Calico opretter en kæde for hver pod (workload) og hooks i INPUT- og OUTPUT-kæderne for workload til filtertabellen i FORWARD-kæden.
Host Endpoints
Host Endpoint Politik (2)
Udover CNI (container network interface) tilbyder Calico politikker, der gør det muligt at beskytte selve værten. I Calico kan du oprette en host endpoint ved at angive en kombination af værtens interface og, hvis nødvendigt, portnumre. Anvendelse af politikker for denne enhed opnås ved hjælp af filtertabellen i INPUT- og OUTPUT-kæderne. Som det fremgår af diagrammet, (2) de anvendes til lokale processer på noden/værten. Det vil sige, hvis du har oprettet en politik, der gælder for host endpoint, vil den ikke påvirke trafikken til/fra dine pods. Men dens anvendelse giver en ensartet grænseflade/syntaks til at blokere trafik for din vært og pods ved hjælp af Calico-politikker. Dette forenkler betydeligt processen med at administrere politikker for heterogene netværk. Konfigurationen af host endpoint-politikker for at styrke sikkerheden i klyngen er et andet vigtigt anvendelsestilfælde.
ApplyOnForward Politik (3)
Muligheden ApplyOnForward er tilgængelig i Calico global network policy for at muliggøre anvendelse af politikker til al trafik, der passerer gennem host endpoint, inklusiv trafik, der vil blive videresendt af værten. Denne trafik inkluderer den, der sendes til den lokale pod eller et andet sted i netværket. Calico kræver, at denne indstilling er aktiveret for politikker, der bruger PreDNAT og untracked, se følgende afsnit. Derudover kan ApplyOnForward bruges til at spore værtens trafik i tilfælde af brug af en virtuel router eller software NAT.
Bemærk, at hvis du skal anvende den samme netværkspolitik for både værtprocesser og pod’er, er det ikke nødvendigt at bruge indstillingen ApplyOnForward. Det er tilstrækkeligt at oprette en label for de relevante hostendpoint og workload endpoint (pod). Calico er intelligent nok til at anvende politikken baseret på labels, uanset typen af endpoint (hostendpoint eller workload).
PreDNAT Politik (4)
I Kubernetes kan service-enhedens porte eksponeres eksternt ved hjælp af NodePorts optionen, eller som et alternativ (ved brug af Calico), ved at erklære dem gennem optionerne Cluster IPs eller External IPs. Kube-proxy balancerer den indgående trafik, der er knyttet til service, til pod’erne i den relevante service ved hjælp af DNAT. I lyset af dette, hvordan anvender du politikker for den trafik, der kommer ind via NodePorts? For at disse politikker kan anvendes, før trafikken behandles af DNAT (som repræsenterer mapping af host:port til den relevante service), tilbyder Calico en parameter for globalNetworkPolicy, der kaldes "preDNAT: true".
Når pre-DNAT er aktiveret, implementeres disse politikker i (4) på diagrammet — i mangle-kæden PREROUTING — lige før DNAT. Den normale rækkefølge af politikker (order) overholdes ikke her, da anvendelsen af disse politikker finder sted meget tidligere i trafikbehandlingsvejen. Alligevel overholder preDNAT-politikker rækkefølgen af anvendelse (order) imellem dem.
Når man opretter politikker med pre-DNAT, er det vigtigt at være opmærksom på den trafik, du ønsker at behandle, og at tillade, at flertallet bliver afvist. Trafik, der er mærket som 'allow' i pre-DNAT-politikken, vil ikke længere blive kontrolleret af hostendpoint-politikken, mens trafik, der fejler i at overholde pre-DNAT-politikken, fortsætter sin vej gennem de øvrige kæder.
Calico har gjort det obligatorisk at aktivere indstillingen applyOnForward, når preDNAT anvendes, da destinationspunktet for trafik endnu ikke er valgt. Trafikken kan rettes mod en værtprocess, eller den kan omdirigeres til en pod eller en anden node.
Untracked Politik (5)
Netværk og applikationer kan have store forskelle i adfærd. I nogle ekstreme tilfælde kan applikationer generere mange kortvarige forbindelser. Dette kan føre til mangel på hukommelse i conntrack (den centrale komponent i Linux-netværksstakken). Traditionelt kræver det, at du manuelt konfigurerer eller deaktiverer conntrack, eller skriver iptables-regler for at omgå conntrack, når du kører denne type applikationer i Linux. Untracked policy i Calico er et simplere og mere effektivt alternativ, hvis du vil håndtere forbindelser så hurtigt som muligt. For eksempel, hvis du bruger en massiv eller som et ekstra sikkerhedslag mod .
Læs dette (eller ) for at få yderligere oplysninger, herunder ydeevnetests ved brug af untracked policy.
Når du angiver indstillingen "doNotTrack: true" i Calico globalNetworkPolicy, bliver den en **untracked** politik og anvendes i det tidligste stadium af Linux-pakkebehandlingsprocessen. Hvis du ser på diagrammet ovenfor, anvendes untracked politikker i PREROUTING og OUTPUT kæderne i raw-tabellen, før forbindelsessporing (conntrack) aktiveres. Når en pakke tillades af untracked politikken, bliver den markeret for at deaktivere forbindessporing for den pakke. Det betyder:
- Untracked politikken anvendes for hver pakke. Der er ikke noget begreb om forbindelse (eller strøm). Manglen på forbindelser fører til flere vigtige konsekvenser:
- Hvis du vil tillade både requests og response trafik, har du brug for en regel både for indgående og udgående (da Calico normalt bruger conntrack til at markerer respons trafik som tilladt).
- Untracked politik fungerer ikke for Kubernetes workloads (pods), da der i dette tilfælde ikke er nogen måde at spore den udgående forbindelse fra en pod.
- NAT fungerer ikke korrekt med untracked pakker (da kernen gemmer NAT-mapping i conntrack).
- Når en pakke passerer gennem reglen "tillad alt" i untracked-politikken, vil alle pakker blive markeret som untracked. Dette er næsten altid ikke det, du ønsker, så det er vigtigt at være meget selektiv med pakker tilladt af untracked-politikker (og lade størstedelen af trafikken passere gennem almindelige trackede politikker).
- Untracked-politikker anvendes i begyndelsen af pakkeprocesseringskæden. Det er meget vigtigt at forstå, når man opretter Calico-politikker. Du kan have en politik for pod’en med order:1 og en untracked-politik med order:1000. Dette vil ikke være vigtigt. Untracked-politikken vil blive anvendt før politikken for pod’en. Untracked-politikker overholder kun rækkefølgen af udførelse mellem dem selv.
Da et af formålene med doNotTrack-politikken er at håndhæve politikker på et tidligt stadium i Linux-pakkeprocesseringskæden, kræver Calico påkrævet at angive indstillingen applyOnForward ved brug af doNotTrack. Når du ser på diagrammet for pakkeprocessering, bemærk, at untracked-politikken (5) anvendes før enhver routingbeslutning. Trafikken kan dirigeres til en host-proces, eller den kan omdirigeres til en pod eller en anden node.
Resumé
Vi har set på forskellige politikmuligheder (Host endpoint, ApplyOnForward, preDNAT og Untracked) i Calico og hvordan de anvendes i pakkeprocesseringen. At forstå essensen af deres funktion hjælper med at udvikle effektive og sikre politikker. Med Calico kan du bruge global netværkspolitik, der anvendes på label (gruppe af noder og pods) og anvende politikker med forskellige parametre. Dette gør det muligt for sikkerheds- og netværksdesignspecialister nemt at beskytte 'alt' (typer endpoints) med et enkelt sprog for politikker med Calico-politikker.
Tak: Jeg vil gerne takke og for deres gennemgang og værdifulde information.
Kilde: habr.com
