Die Calico-netwerkinprop bied 'n wye reeks netwerkbeleide met 'n verenigde sintaksis om hardeware-gashere, virtuele masjiene en peule te beskerm. Hierdie beleide kan binne 'n naamruimte toegepas word of globale netwerkbeleide wees wat van toepassing is op (om toepassings wat direk op die gasheer loop te beskerm - die gasheer kan 'n bediener of 'n virtuele masjien wees) of (om toepassings wat in houers of virtuele masjiene aangebied word, te beskerm). Calico-beleide stel jou in staat om sekuriteitsmaatreëls op verskeie punte in 'n pakkie se pad toe te pas deur opsies soos preDNAT, unraracked en applicationOnForward toe te pas. Om te verstaan hoe hierdie opsies werk, kan help om die sekuriteit en werkverrigting van jou algehele stelsel te verbeter. Hierdie artikel verduidelik die kern van hierdie Calico-beleidsopsies (preDNAT, unraracked en applicationOnForward) wat op gasheer-eindpunte toegepas word, met die klem op wat in pakkieverwerkingspaaie (iptabels-kettings) gebeur.
Hierdie artikel veronderstel dat jy 'n basiese begrip het van hoe Kubernetes- en Calico-netwerkbeleide werk. Indien nie, beveel ons aan om dit te probeer и gebruik Calico voordat u hierdie artikel lees. Ons verwag ook van jou om 'n basiese begrip van die werk te hê in linux.
Calico laat jou toe om 'n stel toegangsreëls deur etikette toe te pas (op groepe gashere en werkladings/peule). Dit is baie nuttig as jy heterogene stelsels saam gebruik - virtuele masjiene, 'n stelsel direk op hardeware, of 'n kubernetes-infrastruktuur. Daarbenewens kan jy jou groepering (nodes) beskerm deur 'n stel verklarende beleide te gebruik en netwerkbeleide op inkomende verkeer toe te pas (byvoorbeeld deur die NodePorts of Eksterne IPs diens).
Op 'n fundamentele vlak, wanneer Calico 'n peul aan die netwerk koppel (sien diagram hieronder), koppel dit dit aan die gasheer met behulp van 'n virtuele Ethernet-koppelvlak (veth). Die verkeer wat deur die peul gestuur word, kom vanaf hierdie virtuele koppelvlak na die gasheer en word op dieselfde manier verwerk asof dit van 'n fisiese netwerkkoppelvlak af kom. By verstek, noem Calico hierdie koppelvlakke caliXXX. Aangesien die verkeer deur die virtuele koppelvlak kom, gaan dit deur iptables asof die peul een stap weg is. Daarom, wanneer verkeer na/van 'n peul kom, word dit vanuit die gasheer se oogpunt aangestuur.
Op 'n Kubernetes-knooppunt wat Calico loop, kan jy 'n virtuele koppelvlak (veth) soos volg na 'n werklading karteer. In die voorbeeld hieronder, kan jy sien dat veth#10 (calic1cbf1ca0f8) gekoppel is aan cnx-manager-* in die calico-monitering 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
...
Gegewe dat Calico 'n vet-koppelvlak vir elke werklading skep, hoe dwing dit beleide af? Om dit te doen, skep Calico hake in verskeie kettings van die pakkieverwerkingspad met behulp van iptables.
Die diagram hieronder toon die kettings wat betrokke is by pakkieverwerking in iptables (of die netfilter-substelsel). Wanneer 'n pakkie deur 'n netwerkkoppelvlak aankom, gaan dit eers deur die PREROUTING-ketting. 'n Roeteringsbesluit word dan geneem, en op grond hiervan gaan die pakkie deur óf INPUT (gerig na gasheerprosesse) óf FORWARD (gerig na 'n pod of 'n ander nodus op die netwerk). Vanaf die plaaslike proses gaan die pakkie deur die UITGANG en dan POSTROUTING-ketting voordat dit deur die kabel gestuur word.
Let daarop dat die peul ook 'n eksterne entiteit is (gekoppel aan die veth) in terme van iptables-verwerking. Kom ons som op:
- Aangestuurde verkeer (natuurlik, geroer of na/van 'n peul) gaan deur die PREROUTING - FORWARD - POSTROUTING kettings.
- Verkeer na die plaaslike gasheerproses gaan deur die PREROUTING - INPUT-ketting.
- Verkeer vanaf die plaaslike gasheerproses gaan deur die OUTPUT - POSTROUTING-ketting.
Calico bied beleidsopsies wat jou toelaat om beleide oor alle kettings toe te pas. Met dit in gedagte, kom ons kyk na die verskillende beleidkonfigurasie-opsies wat in Calico beskikbaar is. Die getalle in die lys opsies hieronder stem ooreen met die getalle in die diagram hierbo.
- Werklading eindpunt (peul) beleid
- Gasheer-eindpuntbeleid
- ApplyOnForward opsie
- PreDNAT-beleid
- Onnagespoorde beleid
Kom ons begin deur te kyk hoe beleide toegepas word op werklading-eindpunte (Kubernetes-peule of OpenStack VM's), en kyk dan na die beleidsopsies vir gasheer-eindpunte.
Werkslading eindpunte
Werklading eindpuntbeleid (1)
Dit is 'n opsie om jou kubernetes-peule te beskerm. Calico ondersteun werk met Kubernetes NetworkPolicy, maar dit verskaf ook bykomende beleide - Calico NetworkPolicy en GlobalNetworkPolicy. Calico skep 'n ketting vir elke peul (werklading) en haak die INPUT- en UITSET-kettings vir die werklading in by die filtertabel van die FORWARD-ketting.
Gasheer eindpunte
Gasheer-eindpuntbeleid (2)
Benewens CNI (houernetwerkkoppelvlak), bied Calico-beleide die vermoë om die gasheer self te beskerm. In Calico kan jy 'n gasheer-eindpunt skep deur 'n kombinasie van die gasheerkoppelvlak en, indien nodig, poortnommers te spesifiseer. Beleidsafdwinging vir hierdie entiteit word bereik deur gebruik te maak van 'n filtertabel in die INVOER- en UITSET-kettings. Soos jy uit die diagram kan sien, (2) is hulle van toepassing op plaaslike prosesse op die nodus/gasheer. Dit wil sê, as jy 'n beleid skep wat van toepassing is op die gasheer-eindpunt, sal dit nie verkeer wat na/van jou peule gaan, beïnvloed nie. Maar dit bied wel 'n enkele koppelvlak/sintaksis om verkeer vir jou gasheer en peule te blokkeer deur Calico-beleide te gebruik. Dit vergemaklik die proses van beleidbestuur vir 'n heterogene netwerk aansienlik. Die opstel van gasheer-eindpuntbeleide om groepsekuriteit te verbeter, is nog 'n belangrike gebruiksgeval.
ApplyOnForward-beleid (3)
Die ApplyOnForward-opsie is beskikbaar in Calico se globale netwerkbeleid om toe te laat dat beleid toegepas word op alle verkeer wat deur die gasheer-eindpunt gaan, insluitend verkeer wat deur die gasheer aangestuur sal word. Dit sluit verkeer in wat na die plaaslike pod of enige ander plek op die netwerk aangestuur word. Calico vereis dat hierdie instelling geaktiveer moet wees vir beleide wat PreDNAT gebruik en ongespoor word, sien die volgende afdelings. Daarbenewens kan ApplyOnForward gebruik word om gasheerverkeer te monitor in gevalle waar 'n virtuele router of sagteware NAT gebruik word.
Let daarop dat as jy dieselfde netwerkbeleid op beide gasheerprosesse en peule moet toepas, jy nie die ApplyOnForward-opsie hoef te gebruik nie. Al wat u hoef te doen is om 'n etiket vir die vereiste gasheer-eindpunt en werklading-eindpunt (pod) te skep. Calico is slim genoeg om beleid op grond van etikette af te dwing, ongeag die eindpunttipe (gasheerpunt of werklading).
PreDNAT-beleid (4)
In Kubernetes kan diensentiteitpoorte ekstern blootgestel word deur die NodePorts-opsie te gebruik of, opsioneel (wanneer Calico gebruik word), deur dit te adverteer deur die Cluster IP's of Eksterne IP's opsies te gebruik. Kube-instaanbediener balanseer inkomende verkeer gebind aan 'n diens na die peule van die ooreenstemmende diens deur gebruik te maak van DNAT. Gegewe dit, hoe dwing jy beleid af vir verkeer wat deur NodePorts kom? Om te verseker dat hierdie beleide toegepas word voordat die verkeer deur DNAT verwerk word (wat 'n kartering tussen gasheer:poort en ooreenstemmende diens is), verskaf Calico 'n parameter vir globale netwerkbeleid genaamd "preDNAT: true".
Wanneer pre-DNAT geaktiveer is, word hierdie beleide geïmplementeer in (4) in die diagram - in die mangle-tabel van die PREROUTING-ketting - onmiddellik voor DNAT. Die gewone volgorde van beleide word nie hier gevolg nie, aangesien die toepassing van hierdie beleide baie vroeër in die verkeersverwerkingspad plaasvind. PreDNAT-beleide respekteer egter die volgorde van toepassing onder mekaar.
Wanneer jy beleide met pre-DNAT skep, is dit belangrik om versigtig te wees oor die verkeer wat jy wil verwerk en toelaat dat die meerderheid verwerp word. Verkeer wat as 'toelaat' in die pre-DNAT-beleid gemerk is, sal nie meer deur die gasheerpuntbeleid gekontroleer word nie, terwyl verkeer wat die pre-DNAT-beleid misluk, deur die oorblywende kettings sal voortgaan.
Calico het dit verpligtend gemaak om die applicationOnForward-opsie te aktiveer wanneer preDNAT gebruik word, aangesien die bestemming van die verkeer per definisie nog nie gekies is nie. Verkeer kan na die gasheerproses gelei word, of dit kan na 'n peul of 'n ander nodus aangestuur word.
Ongespoorde beleid (5)
Netwerke en toepassings kan groot verskille in gedrag hê. In sommige uiterste gevalle kan toepassings baie kortstondige verbindings genereer. Dit kan veroorsaak dat conntrack ('n kernkomponent van die Linux-netwerkstapel) se geheue opraak. Tradisioneel, om hierdie tipe toepassings op Linux te laat loop, sal jy conntrack handmatig moet konfigureer of deaktiveer, of iptables-reëls moet skryf om conntrack te omseil. Ongespoorde beleid in Calico is 'n eenvoudiger en doeltreffender opsie as jy verbindings so vinnig as moontlik wil verwerk. Byvoorbeeld, as jy massiewe gebruik of as 'n bykomende maatreël van beskerming teen .
Lees hierdie (Of ) vir meer inligting, insluitend prestasietoetse wat ongespoorde beleid gebruik.
Wanneer jy die "doNotTrack: true"-opsie in Calico globalNetworkPolicy stel, word dit 'n **ongespoorde**-beleid en word baie vroeg in die Linux-pakkieverwerkingspyplyn toegepas. As ons na die diagram hierbo kyk, word ongespoorde beleide toegepas in die PREROUTING- en OUTPUT-kettings in die rou tabel voordat konneksieopsporing (conntrack) begin word. Wanneer 'n pakkie deur die ongespoorde beleid toegelaat word, word dit gemerk om verbindingnasporing vir daardie pakkie te deaktiveer. Dit beteken:
- Die ongespoorde beleid word op 'n per-pakkie-basis toegepas. Daar is geen konsep van verband (of vloei) nie. Gebrek aan verbindings het verskeie belangrike gevolge:
- As jy beide versoek- en reaksieverkeer wil toelaat, benodig jy 'n reël vir beide inkomende en uitgaande (aangesien Calico tipies conntrack gebruik om reaksieverkeer as toegelaat te merk).
- Die ongespoorde beleid werk nie vir Kubernetes-werkladings (peule) nie, want in hierdie geval is daar geen manier om die uitgaande verbinding vanaf die peul na te spoor nie.
- NAT werk nie korrek met pakkies wat nie nagespoor is nie (aangesien die kern die NAT-kartering in conntrack stoor).
- Wanneer deur die "laat alles toe"-reël in die ongespoorde beleid deurgegaan word, sal alle pakkies as ongespoor gemerk word. Dit is amper altyd nie wat jy wil hê nie, so dit is belangrik om baie selektief te wees oor die pakkies wat toegelaat word deur ongespoorde beleide (en toelaat dat die meeste verkeer deur normale nagespoorde beleide gaan).
- Onnagespoorde beleide word heel aan die begin van die pakkieverwerkingspyplyn toegepas. Dit is baie belangrik om te verstaan wanneer jy Calico-beleide skep. Jy kan 'n pod-polis hê met bestelling:1 en 'n ongespoorde polis met bestelling:1000. Dit sal nie saak maak nie. Die ongespoorde polis sal voor die polis vir die peul toegepas word. Ongespoorde polisse respekteer uitvoeringsbevel slegs onder mekaar.
Omdat een van die doelwitte van die doNotTrack-beleid is om die beleid baie vroeg in die Linux-pakkieverwerkingspyplyn af te dwing, maak Calico dit verpligtend om die applicationOnForward-opsie te spesifiseer wanneer doNotTrack gebruik word. Met verwysing na die pakkieverwerkingsdiagram, let op dat die ongespoorde(5)-beleid toegepas word voor enige roetebesluite. Verkeer kan na die gasheerproses gelei word, of dit kan na 'n peul of 'n ander nodus aangestuur word.
Resultate van
Ons het na die verskillende beleidsopsies (Host-eindpunt, ApplyOnForward, preDNAT en Untracked) in Calico gekyk en hoe dit langs die pakkieverwerkingspad toegepas word. Om te verstaan hoe hulle werk, help met die ontwikkeling van effektiewe en veilige beleide. Met Calico kan jy 'n globale netwerkbeleid gebruik wat van toepassing is op 'n etiket ('n groep nodusse en peule) en beleide met verskeie parameters toepas. Dit stel sekuriteits- en netwerkontwerppersoneel in staat om "alles" (eindpunttipes) gerieflik te beskerm deur 'n enkele beleidstaal met Calico-beleide te gebruik.
Erkenning: Ek wil graag bedank и vir hul hersiening en waardevolle inligting.
Bron: will.com