De netwerplugin Calico biedt een breed scala aan netwerkbeleid met een uniforme syntaxis voor de bescherming van hosts op fysieke machines, virtuele machines en podās. Deze beleidsregels kunnen worden toegepast binnen een namespace of als globale netwerkbeleidsregels die van toepassing zijn op (voor de bescherming van applicaties die direct op de host draaien ā een host kan een server of een virtuele machine zijn) of op (voor de bescherming van applicaties die draaien in container of virtuele machines die op de host zijn geplaatst). De beleidsregels van Calico maken het mogelijk om beveiligingsmaatregelen toe te passen op verschillende pakketpaden met opties zoals preDNAT, unraracked en applyOnForward. Inzicht in hoe deze opties werken kan helpen om de veiligheid en de prestaties van het systeem als geheel te verbeteren. In dit artikel wordt de essentie van deze beleidsparameters van Calico (preDNAT, unraracked en applyOnForward) die van toepassing zijn op host endpoints uitgelegd, met de nadruk op wat er gebeurt in de pakketverwerkingspaden (iptabels ketens).
Dit artikel gaat ervan uit dat je de basisprincipes van netwerkbeleidsregels in Kubernetes en Calico begrijpt. Zo niet, raden we aan om de en te volgen met behulp van Calico voordat je dit artikel leest. We gaan er ook vanuit dat je basiskennis hebt van het werken in Linux.
, dat de standaard API-set van Kubernetes aanzienlijk uitbreidt op het gebied van netwerkinstellingen. maakt het mogelijk om een set toegangregels op labels toe te passen (op groepen hosts en workloads/pods). Dit is zeer nuttig als je verschillende systemen samen gebruikt ā virtuele machines, systemen die op fysieke hardware draaien of Kubernetes-infrastructuur. Bovendien kun je je cluster (nodes) beschermen met een set declaratieve beleidsregels en netwerkbeleidsregels toepassen op inkomend verkeer (bijvoorbeeld via NodePorts of externe IP's).
Op fundamenteel niveau, wanneer Calico een pod met het netwerk verbindt (zie het diagram hieronder), verbindt het deze met de host via een virtuele Ethernet-interface (veth). Verkeer dat door de pod wordt verzonden, komt op de host binnen via deze virtuele interface en wordt behandeld alsof het van een fysieke netwerkinterface afkomstig is. Standaard noemt Calico deze interfaces caliXXX. Aangezien het verkeer via de virtuele interface binnenkomt, gaat het door iptables, alsof de pod Ć©Ć©n hopafstand verwijderd is. Daarom, wanneer verkeer van of naar de pod komt, wordt het doorgestuurd vanuit het perspectief van de host.
Op de Kubernetes-node waar Calico draait, kunt u de virtuele interface (veth) met de workload op de volgende manier in kaart brengen. In het onderstaande voorbeeld ziet u dat veth#10 (calic1cbf1ca0f8) is verbonden met cnx-manager-* in de 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
... 
Gegeven dat Calico een veth-interface voor elke workload creƫert, hoe past het beleid toe? Hiervoor creƫert Calico hooks in verschillende ketens van het pakketverwerkingspad, gebruikmakend van iptables.
In het onderstaande diagram staan de ketens die betrokken zijn bij de pakketverwerking in iptables (of netfilter-subsysteem). Wanneer een pakket via de netwerkinterface binnenkomt, doorloopt het eerst de keten PREROUTING. Vervolgens wordt een routingsbesluit genomen, en op basis hiervan gaat het pakket ofwel door INPUT (bestemd voor processen op de host), of door FORWARD (bestemd voor de pod of een andere node in het netwerk). Vanuit een lokaal proces gaat het pakket door OUTPUT en daarna POSTROUTING voordat het via de kabel wordt verzonden.
Let op dat de pod ook een extern object is (verbonden met veth) vanuit het perspectief van iptables-verwerking. Samenvattend:
- Doorgestuurd (forwarded) verkeer (NAT, routable of in/uit pod) gaat door de ketens PREROUTING ā FORWARD ā POSTROUTING.
- Verkeer naar de lokale host-proces gaat door de keten PREROUTING ā INPUT.
- Verkeer van het lokale host-proces gaat door de keten OUTPUT ā POSTROUTING.
Calico biedt opties voor beleid waarmee je beleidsregels voor alle ketens kunt toepassen. Met dit in gedachten, laten we de verschillende configuratiemogelijkheden van beleid in Calico bekijken. De cijfers in de onderstaande lijst komen overeen met de cijfers op de bovenstaande diagram.
- Workload endpoint (pod) beleid
- Host endpoint beleid
- Optie ApplyOnForward
- PreDNAT beleid
- Untracked beleid
Laten we beginnen met te kijken naar hoe beleid wordt toegepast op workload endpoints (Kubernetes pods of OpenStack VMs), en daarna bekijken we de beleidsopties voor host endpoints.
Workload Endpoints
Workload Endpoint Beleid (1)
Dit is een optie voor de bescherming van je Kubernetes pods. Calico ondersteunt de werking met Kubernetes NetworkPolicy, maar biedt ook aanvullende beleidsregels - Calico NetworkPolicy en GlobalNetworkPolicy. Calico creƫert een keten voor elke pod (workload) en haakt in op de INPUT en OUTPUT ketens voor workload naar de FORWARD filterketen.
Host Endpoints
Host Endpoint Beleid (2)
Naast CNI (container network interface), biedt Calico beleidsopties voor directe bescherming van de host. In Calico kun je een host endpoint creƫren door een combinatie van de hostinterface en, indien nodig, poortnummers op te geven. Toepassing van beleid voor deze entiteit wordt gerealiseerd via een filterschema in de INPUT en OUTPUT ketens. Zoals te zien is in de diagram, worden (2) ze toegepast op lokale processen op de node/host. Dit betekent dat als je een beleid hebt gecreƫerd dat van toepassing is op de host endpoint, dit geen invloed zal hebben op het verkeer dat naar/van je pods gaat. Maar het zorgt voor een uniforme interface/syntax voor het blokkeren van verkeer voor je host en pods met behulp van Calico beleidsregels. Dit vereenvoudigt het proces van het beheren van beleid voor een heterogeen netwerk aanzienlijk. Het configureren van host endpoint beleid voor het versterken van de beveiliging van het cluster is een andere belangrijke gebruikszaak.
ApplyOnForward Beleid (3)
De optie ApplyOnForward is beschikbaar in Calico global network policy, om de toepassing van beleid op al het verkeer dat door de host endpoint gaat mogelijk te maken, inclusief verkeer dat door de host wordt doorgestuurd. Dit verkeer omvat verkeer dat naar een lokale pod of ergens anders in het netwerk wordt doorgestuurd. Calico vereist dat deze parameter is ingeschakeld voor beleid dat PreDNAT en untracked gebruikt; zie de volgende secties. Bovendien kan ApplyOnForward worden gebruikt voor het volgen van het hostverkeer in gevallen waarin een virtuele router of softwarematige NAT wordt gebruikt.
Merk op dat als je hetzelfde netwerkbeleid voor zowel hostprocessen als pod's wilt toepassen, je de optie ApplyOnForward niet hoeft te gebruiken. Het is voldoende om een label te creƫren voor de benodigde hostendpoint en workload endpoint (pod). Calico is slim genoeg om het beleid toe te passen op basis van labels, ongeacht het type endpoint (hostendpoint of workload).
PreDNAT-beleid (4)
In Kubernetes kunnen de poorten van de service-entiteit extern worden doorgestuurd met behulp van de optie NodePorts of, optioneel (bij gebruik van Calico), door ze te declareren via de opties Cluster IP's of External IP's. Kube-proxy balanceert het inkomende verkeer dat aan de service is gekoppeld naar de pod's van de overeenkomstige service met behulp van DNAT. Gegeven dit, hoe pas je de beleidsregels toe voor verkeer dat via NodePorts binnenkomt? Om deze beleidsregels toe te passen voordat het verkeer wordt behandeld door DNAT (de mapping van host:poort naar de overeenkomstige service), biedt Calico een parameter voor globalNetworkPolicy aan die āpreDNAT: trueā heet.
Wanneer pre-DNAT is ingeschakeld, worden deze beleidsregels geĆÆmplementeerd in (4) op het diagram ā in de mangle-tabel van de PREROUTING-keten ā direct vĆ³Ć³r DNAT. De gebruikelijke volgorde van beleidsregels (order) wordt hier niet gevolgd, aangezien de toepassing van deze beleidsregels veel eerder in het verwerkingspad van het verkeer plaatsvindt. Desondanks houden de preDNAT-beleidsregels zich aan de toepassingsvolgorde (order) onderling.
Bij het maken van beleidsregels met pre-DNAT is het belangrijk om aandacht te besteden aan het verkeer dat je wilt verwerken en het merendeel af te laten wijzen. Verkeer dat in de pre-DNAT-beleidsregel als 'allow' is gemarkeerd, wordt niet meer gecontroleerd door de hostendpoint-beleidsregel, terwijl verkeer dat niet slaagt voor de pre-DNAT-beleidsregel zijn weg zal voortzetten door de overige ketens.
Calico heeft de optie applyOnForward verplicht gemaakt bij gebruik van preDNAT, omdat volgens definities de bestemming van het verkeer nog niet is gekozen. Verkeer kan naar een hostproces worden geleid, of het kan worden doorgestuurd naar een pod of een andere node.
Untracked-beleid (5)
Netwerken en applicaties kunnen grote verschillen in gedrag vertonen. In sommige extreme gevallen kunnen applicaties talloze kortdurende verbindingen genereren. Dit kan leiden tot geheugenproblemen bij conntrack (de belangrijkste component van de Linux-netwerkstack). Traditioneel gezien moet u om dit soort applicaties in Linux te starten, conntrack handmatig configureren of uitschakelen, of iptables-regels schrijven om conntrack te omzeilen. Untracked policy in Calico is een eenvoudiger en effectiever alternatief als u verbindingen zo snel mogelijk wilt verwerken. Bijvoorbeeld, als u een massief of als aanvullende beveiligingsmaatregel tegen .
Lees deze (of ) voor meer informatie, inclusief prestatie-tests bij het gebruik van untracked policy.
Wanneer u de optie "doNotTrack: true" instelt in Calico globalNetworkPolicy, wordt het een **onbehandelde** policy en toegepast in een zeer vroeg stadium van de Linux-pakketverwerkingspijplijn. Als we naar het diagram hierboven kijken, worden untracked policies toegepast in de PREROUTING en OUTPUT ketens in de raw tabel, voordat het verbinden van verbindingen (conntrack) wordt gestart. Wanneer een pakket door untracked policy wordt toegestaan, wordt het gemarkeerd om het verbinden van verbindingen voor dat pakket uit te schakelen. Dit betekent:
- Untracked policy wordt toegepast op elk pakket. Er is geen sprake van verbinding (of stroom). Het ontbreken van verbindingen (connection) heeft verschillende belangrijke gevolgen:
- Als u zowel het verzoek- als het antwoordverkeer wilt toestaan, heeft u een regel nodig voor zowel inkomende als uitgaande verkeer (omdat Calico doorgaans gebruikmaakt van conntrack om het antwoordverkeer als toegestaan te markeren).
- Untracked policy werkt niet voor Kubernetes workloads (pods), omdat er in dit geval geen manier is om de uitgaande verbinding vanuit de pod te volgen.
- NAT werkt niet correct met niet-getrackte pakketten (omdat de kernel de NAT-koppeling in conntrack opslaat).
- Wanneer pakketten door de "toestaan allemaal" regel in untracked policy gaan, zullen alle pakketten als niet-getrackte pakketten worden gemarkeerd. Dit is bijna altijd niet wat u wilt, dus het is belangrijk om selectief te zijn bij de pakketten die door untracked policies worden toegestaan (en om het merendeel van het verkeer via gewone getrackte policies te laten verlopen).
- Untracked-beleid wordt toegepast aan het begin van de pakketverwerkingspijplijn. Het is belangrijk om dit te begrijpen bij het creĆ«ren van Calico-beleidsregels. U kunt een beleid hebben voor een pod met order:1 en een untracked-beleid met order:1000. Dit zal niet relevant zijn. Het untracked-beleid zal vĆ³Ć³r het beleid voor de pod worden toegepast. Untracked-beleid respecteert alleen de uitvoeringsvolgorde tussen zichzelf.
Aangezien een van de doelstellingen van het doNotTrack-beleid is om het beleid in de vroegste fase van de Linux-pakketverwerkingspijplijn af te dwingen, maakt Calico het verplicht om de optie applyOnForward op te geven bij het gebruik van doNotTrack. Kijkend naar het pakketverwerkingsdiagram, merkt u op dat het untracked-beleid (5) wordt toegepast vĆ³Ć³r enige routeringsbeslissingen. Verkeer kan worden doorgestuurd naar een hostproces, of het kan worden omgeleid naar een pod of een andere node.
Conclusies
We hebben verschillende beleidsopties (Host endpoint, ApplyOnForward, preDNAT, en Untracked) in Calico bekeken en hoe ze worden toegepast in de pakketverwerkingsweg. Begrip van hun werking helpt bij het creƫren van effectieve en veilige beleidsregels. Met Calico kunt u gebruik maken van een global network policy, die wordt toegepast op labels (groepen van nodes en pods) en beleidsregels toepassen met verschillende parameters. Dit stelt netwerk- en beveiligingsspecialisten in staat om eenvoudig "alles" (soorten endpoints) te beschermen met een uniforme taal van beleidsregels met Calico-beleidsregel.
Dankbetuiging: Ik wil graag bedanken en voor hun feedback en waardevolle inzichten.
Bron: habr.com
