De Calico-netwerkplug-in biedt een breed scala aan netwerkbeleidsregels met een uniforme syntaxis om hardwarehosts, virtuele machines en pods te beschermen. Dit beleid kan worden toegepast binnen een naamruimte of kan globaal netwerkbeleid zijn dat van toepassing is (om applicaties te beschermen die rechtstreeks op de host draaien - de host kan een server of een virtuele machine zijn) of (om applicaties te beschermen die in containers of gehoste virtuele machines draaien). Met Calico-beleid kunt u op verschillende punten in het pad van een pakket beveiligingsmaatregelen toepassen met behulp van opties zoals preDNAT, unraracked en applyOnForward. Als u begrijpt hoe deze opties werken, kunt u de beveiliging en prestaties van uw algehele systeem verbeteren. In dit artikel wordt de essentie uitgelegd van deze Calico-beleidsopties (preDNAT, unraracked en applyOnForward) toegepast op host-eindpunten, met de nadruk op wat er gebeurt in pakketverwerkingspaden (iptabels-ketens).
In dit artikel wordt ervan uitgegaan dat u basiskennis heeft van hoe het netwerkbeleid van Kubernetes en Calico werkt. Als dit niet het geval is, raden we u aan het te proberen и Calico gebruiken voordat u dit artikel leest. Daarnaast verwachten wij dat je enige basiskennis hebt van het werk op linux.
Calico Hiermee kunt u een reeks toegangsregels toepassen via labels (op groepen hosts en werkbelastingen/pods). Dit is erg handig als u heterogene systemen samen gebruikt: virtuele machines, een systeem rechtstreeks op hardware of een Kubernetes-infrastructuur. Bovendien kunt u uw cluster (knooppunten) beschermen met behulp van een reeks declaratieve beleidsregels en netwerkbeleid toepassen op inkomend verkeer (bijvoorbeeld via de NodePorts- of External IPs-service).
Op een fundamenteel niveau, wanneer Calico een pod op het netwerk aansluit (zie diagram hieronder), verbindt het deze met de host via een virtuele Ethernet-interface (veth). Het verkeer dat door de pod wordt verzonden, komt vanuit deze virtuele interface naar de host en wordt op dezelfde manier verwerkt alsof het afkomstig is van een fysieke netwerkinterface. Standaard noemt Calico deze interfaces caliXXX. Omdat het verkeer via de virtuele interface komt, gaat het door iptables alsof de pod slechts één stap verwijderd is. Wanneer verkeer van/naar een pod komt, wordt dit daarom doorgestuurd vanuit het oogpunt van de host.
Op een Kubernetes-knooppunt waarop Calico wordt uitgevoerd, kunt u als volgt een virtuele interface (veth) aan een werklast toewijzen. In het onderstaande voorbeeld kun je zien dat veth#10 (calic1cbf1ca0f8) is verbonden met cnx-manager-* in de calico-monitoring naamruimte.
[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
...
Hoe wordt het beleid afgedwongen, aangezien Calico voor elke werklast een veth-interface creëert? Om dit te doen, creëert Calico hooks in verschillende ketens van het pakketverwerkingspad met behulp van iptables.
Het onderstaande diagram toont de ketens die betrokken zijn bij pakketverwerking in iptables (of het netfilter-subsysteem). Wanneer een pakket via een netwerkinterface arriveert, gaat het eerst door de PREROUTING-keten. Vervolgens wordt er een routeringsbeslissing genomen en op basis hiervan gaat het pakket via INPUT (gericht op hostprocessen) of FORWARD (gericht op een pod of een ander knooppunt op het netwerk). Vanuit het lokale proces gaat het pakket door de OUTPUT- en vervolgens de POSTROUTING-keten voordat het via de kabel wordt verzonden.
Merk op dat de pod ook een externe entiteit is (verbonden met de veth) in termen van iptables-verwerking. Laten we het samenvatten:
- Doorgestuurd verkeer (nat, gerouteerd of van/naar een pod) passeert de PREROUTING - FORWARD - POSTROUTING-ketens.
- Verkeer naar het lokale hostproces passeert de PREROUTING - INPUT-keten.
- Verkeer van het lokale hostproces loopt via de keten OUTPUT - POSTROUTING.
Calico biedt beleidsopties waarmee u beleid over alle ketens heen kunt toepassen. Laten we, met dat in gedachten, eens kijken naar de verschillende beleidsconfiguratieopties die beschikbaar zijn in Calico. De nummers in de onderstaande lijst met opties komen overeen met de nummers in het bovenstaande diagram.
- Beleid voor werkbelastingeindpunt (pod).
- Host-eindpuntbeleid
- ApplyOnForward-optie
- PreDNAT-beleid
- Niet-bijgehouden beleid
Laten we beginnen met te kijken hoe beleid wordt toegepast op werkbelastingeindpunten (Kubernetes-pods of OpenStack-VM's) en vervolgens kijken naar de beleidsopties voor hosteindpunten.
Werkbelastingeindpunten
Eindpuntbeleid voor werkbelasting (1)
Dit is een optie om uw Kubernetes-pods te beschermen. Calico ondersteunt het werken met Kubernetes NetworkPolicy, maar biedt ook aanvullend beleid: Calico NetworkPolicy en GlobalNetworkPolicy. Calico maakt een keten voor elke pod (werklast) en koppelt de INPUT- en OUTPUT-ketens voor de werklast aan de filtertabel van de FORWARD-keten.
Host-eindpunten
Host-eindpuntbeleid (2)
Naast CNI (containernetwerkinterface) biedt Calico-beleid de mogelijkheid om de host zelf te beschermen. In Calico kunt u een hosteindpunt maken door een combinatie van de hostinterface en, indien nodig, poortnummers op te geven. Beleidshandhaving voor deze entiteit wordt bereikt met behulp van een filtertabel in de INPUT- en OUTPUT-ketens. Zoals u in het diagram kunt zien, (2) zijn ze van toepassing op lokale processen op het knooppunt/de host. Dat wil zeggen: als u een beleid maakt dat van toepassing is op het hosteindpunt, heeft dit geen invloed op het verkeer dat van/naar uw peulen gaat. Maar het biedt wel een enkele interface/syntaxis voor het blokkeren van verkeer voor uw host en pods met behulp van Calico-beleid. Dit vereenvoudigt het proces van het beheren van beleid voor een heterogeen netwerk aanzienlijk. Het configureren van host-eindpuntbeleid om de clusterbeveiliging te verbeteren is een ander belangrijk gebruiksscenario.
ApplyOnForward-beleid (3)
De optie ApplyOnForward is beschikbaar in het wereldwijde netwerkbeleid van Calico, zodat beleid kan worden toegepast op al het verkeer dat door het hosteindpunt gaat, inclusief verkeer dat door de host wordt doorgestuurd. Dit omvat verkeer dat wordt doorgestuurd naar de lokale pod of ergens anders op het netwerk. Calico vereist dat deze instelling is ingeschakeld voor beleid dat PreDNAT gebruikt en niet wordt gevolgd, zie de volgende secties. Bovendien kan ApplyOnForward worden gebruikt om hostverkeer te monitoren in gevallen waarin een virtuele router of software-NAT wordt gebruikt.
Houd er rekening mee dat als u hetzelfde netwerkbeleid moet toepassen op zowel hostprocessen als pods, u de optie ApplyOnForward niet hoeft te gebruiken. Het enige dat u hoeft te doen, is een label maken voor het vereiste hostendpoint en workload-eindpunt (pod). Calico is slim genoeg om beleid af te dwingen op basis van labels, ongeacht het type endpoint (hostendpoint of workload).
PreDNAT-beleid (4)
In Kubernetes kunnen service-entiteitspoorten extern worden weergegeven met behulp van de NodePorts-optie of, optioneel (bij gebruik van Calico), door ze te adverteren met behulp van de Cluster-IP's of Externe IP's-opties. Kube-proxy verdeelt inkomend verkeer dat aan een service is gebonden, met behulp van DNAT naar de pods van de overeenkomstige service. Hoe kunt u, gezien dit alles, beleid afdwingen voor verkeer dat via NodePorts binnenkomt? Om ervoor te zorgen dat dit beleid wordt toegepast voordat het verkeer wordt verwerkt door DNAT (wat een mapping is tussen host:port en de bijbehorende service), biedt Calico een parameter voor globalNetworkPolicy genaamd "preDNAT: true".
Wanneer pre-DNAT is ingeschakeld, wordt dit beleid geïmplementeerd in (4) in het diagram - in de mangeltabel van de PREROUTING-keten - onmiddellijk vóór DNAT. De gebruikelijke volgorde van beleid wordt hier niet gevolgd, omdat de toepassing van dit beleid veel eerder in het verkeersverwerkingspad plaatsvindt. PreDNAT-beleid respecteert echter de onderlinge toepassingsvolgorde.
Bij het maken van beleid met pre-DNAT is het belangrijk om voorzichtig te zijn met het verkeer dat u wilt verwerken en toe te staan dat het merendeel wordt afgewezen. Verkeer dat in het pre-DNAT-beleid als 'toestaan' is gemarkeerd, wordt niet langer gecontroleerd door het hostendpoint-beleid, terwijl verkeer dat niet voldoet aan het pre-DNAT-beleid door de resterende ketens zal worden voortgezet.
Calico heeft het verplicht gesteld om de optie applyOnForward in te schakelen bij gebruik van preDNAT, omdat per definitie de bestemming van het verkeer nog niet is geselecteerd. Verkeer kan naar het hostproces worden geleid, of kan worden doorgestuurd naar een pod of een ander knooppunt.
Niet-bijgehouden beleid (5)
Netwerken en applicaties kunnen grote verschillen in gedrag vertonen. In sommige extreme gevallen kunnen applicaties veel kortstondige verbindingen genereren. Dit kan ertoe leiden dat conntrack (een kerncomponent van de Linux-netwerkstack) onvoldoende geheugen heeft. Traditioneel zou je, om dit soort applicaties op Linux uit te voeren, conntrack handmatig moeten configureren of uitschakelen, of iptables-regels moeten schrijven om conntrack te omzeilen. Untracked policy in Calico is een eenvoudigere en efficiëntere optie als u verbindingen zo snel mogelijk wilt verwerken. Als u bijvoorbeeld massief gebruikt of als aanvullende beschermingsmaatregel tegen .
Lees dit (Of ) voor meer informatie, inclusief prestatietests met niet-bijgehouden beleid.
Wanneer u de optie "doNotTrack: true" in Calico globalNetworkPolicy instelt, wordt het een **niet-bijgehouden** beleid en wordt het zeer vroeg in de Linux-pakketverwerkingspijplijn toegepast. Als we naar het bovenstaande diagram kijken, wordt niet-bijgehouden beleid toegepast in de PREROUTING- en OUTPUT-ketens in de onbewerkte tabel voordat het volgen van verbindingen (conntrack) wordt gestart. Wanneer een pakket wordt toegestaan door het niet-bijgehouden beleid, wordt het volgen van de verbinding voor dat pakket uitgeschakeld. Het betekent:
- Het niet-bijgehouden beleid wordt per pakket toegepast. Er is geen concept van verbinding (of stroom). Gebrek aan verbindingen heeft verschillende belangrijke gevolgen:
- Als u zowel aanvraag- als responsverkeer wilt toestaan, heeft u een regel nodig voor zowel inkomend als uitgaand verkeer (aangezien Calico doorgaans conntrack gebruikt om responsverkeer als toegestaan te markeren).
- Het niet-bijgehouden beleid werkt niet voor Kubernetes-workloads (pods), omdat er in dit geval geen manier is om de uitgaande verbinding vanaf de pod te volgen.
- NAT werkt niet correct met niet-getraceerde pakketten (aangezien de kernel de NAT-toewijzing opslaat in conntrack).
- Wanneer u de regel 'alles toestaan' in het niet-bijgehouden beleid doorloopt, worden alle pakketten gemarkeerd als niet-bijgehouden. Dit is bijna altijd niet wat u wilt, dus het is belangrijk om zeer selectief te zijn met betrekking tot de pakketten die zijn toegestaan door niet-bijgehouden beleid (en het meeste verkeer door het normale bijgehouden beleid te laten gaan).
- Niet-bijgehouden beleid wordt helemaal aan het begin van de pakketverwerkingspijplijn toegepast. Dit is erg belangrijk om te begrijpen bij het maken van Calico-beleid. U kunt een podbeleid hebben met bestelling:1 en een beleid zonder tracking met bestelling:1000. Het maakt niet uit. Het beleid voor niet-bijgehouden wordt toegepast vóór het beleid voor de pod. Niet-bijgehouden beleid respecteert de uitvoeringsvolgorde alleen onderling.
Omdat een van de doeleinden van het doNotTrack-beleid is om het beleid zeer vroeg in de Linux-pakketverwerkingspijplijn af te dwingen, maakt Calico het verplicht om de optie applyOnForward op te geven bij gebruik van doNotTrack. Verwijzend naar het pakketverwerkingsdiagram, merk op dat het untracked(5) beleid wordt toegepast vóór routeringsbeslissingen. Verkeer kan naar het hostproces worden geleid, of kan worden doorgestuurd naar een pod of een ander knooppunt.
Resultaten van
We hebben gekeken naar de verschillende beleidsopties (Host endpoint, ApplyOnForward, preDNAT en Untracked) in Calico en hoe deze worden toegepast langs het pakketverwerkingspad. Begrijpen hoe ze werken, helpt bij het ontwikkelen van effectief en veilig beleid. Met Calico kunt u een globaal netwerkbeleid gebruiken dat van toepassing is op een label (een groep knooppunten en pods) en beleid toepassen met verschillende parameters. Hierdoor kunnen beveiligings- en netwerkontwerpprofessionals gemakkelijk “alles” (eindpunttypen) in één keer beschermen met behulp van één enkele beleidstaal met Calico-beleid.
Dankbetuiging: Ik wil graag bedanken и voor hun beoordeling en waardevolle informatie.
Bron: www.habr.com