De Calico-netwurkplugin biedt in breed oanbod fan netwurkbelied mei in unifoarme syntaksis om hardwarehosts, firtuele masines en pods te beskermjen. Dit belied kin tapast wurde binnen in nammeromte of wrâldwide netwurkbelied wêze dat jildt foar (om applikaasjes te beskermjen dy't direkt op 'e host rinne - de host kin in tsjinner as in firtuele masine wêze) of (om applikaasjes te beskermjen dy't rinne yn konteners of hosted firtuele masines). Calico-belied lit jo befeiligingsmaatregels tapasse op ferskate punten yn it paad fan in pakket mei opsjes lykas preDNAT, unraracked, en applyOnForward. Begryp hoe't dizze opsjes wurkje kin helpe om de feiligens en prestaasjes fan jo algemiene systeem te ferbetterjen. Dit artikel ferklearret de essinsje fan dizze Calico-beliedsopsjes (preDNAT, unraracked en applyOnForward) tapast op host-einpunten, mei in klam op wat bart yn pakketferwurkingspaden (iptabels-keatlingen).
Dit artikel giet derfan út dat jo in basisbegryp hawwe fan hoe't Kubernetes en Calico netwurkbelied wurket. As net, riede wy oan om it te besykjen и brûke Calico foardat jo dit artikel lêze. Wy ferwachtsje ek dat jo in basisbegryp hawwe fan it wurk yn linux.
Calico kinne jo in set tagongsregels tapasse troch labels (op groepen fan hosts en workloads / pods). Dit is heul handich as jo heterogene systemen tegearre brûke - firtuele masines, in systeem direkt op hardware, of in kubernetes-ynfrastruktuer. Derneist kinne jo jo kluster (knooppunten) beskermje mei in set fan deklaratyf belied en netwurkbelied tapasse op ynkommende ferkear (bygelyks fia de NodePorts of External IPs tsjinst).
Op in fûnemintele nivo, doe't Calico ferbynt in pod oan it netwurk (sjoch diagram hjirûnder), ferbynt it mei de host mei help fan in firtuele Ethernet ynterface (veth). It ferkear ferstjoerd troch de pod komt nei de host fan dizze firtuele ynterface en wurdt ferwurke op deselde wize as as it kaam fan in fysike netwurkynterface. Standert neamt Calico dizze ynterfaces caliXXX. Sûnt it ferkear komt troch de firtuele ynterface, giet it troch iptables as wie de pod ien hop fuort. Dêrom, as ferkear komt nei/fan in pod, wurdt it trochstjoerd út it eachpunt fan de host.
Op in Kubernetes-knooppunt dy't Calico rint, kinne jo in firtuele ynterface (veth) yn kaart bringe nei in wurkdruk as folget. Yn it foarbyld hjirûnder kinne jo sjen dat veth#10 (calic1cbf1ca0f8) ferbûn is mei cnx-manager-* yn 'e calico-monitoring nammeromte.
[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
...
Sjoen dat Calico in veth-ynterface makket foar elke wurkdruk, hoe hanthavenet it belied? Om dit te dwaan, makket Calico haken yn ferskate keatlingen fan it pakketferwurkingspaad mei iptables.
It diagram hjirûnder toant de keatlingen belutsen by pakketferwurking yn iptables (as it netfilter-subsysteem). As in pakket fia in netwurkynterface komt, giet it earst troch de PREROUTING-ketting. In routingbeslút wurdt dan makke, en op basis dêrfan giet it pakket troch INPUT (rjochte op hostprosessen) of FORWARD (rjochte nei in pod of in oar knooppunt op it netwurk). Fanút it lokale proses giet it pakket troch de OUTPUT en dan POSTROUTING-ketting foardat it troch de kabel ferstjoerd wurdt.
Tink derom dat de pod ek in eksterne entiteit is (ferbûn mei de veth) yn termen fan iptables-ferwurking. Litte wy gearfetsje:
- Trochstjoerd ferkear (nat, routed of nei / fan in pod) giet troch de PREROUTING - FORWARD - POSTROUTING keatlingen.
- Ferkear nei it lokale hostproses giet troch de PREROUTING - INPUT-ketting.
- Ferkear fan it lokale hostproses giet troch de OUTPUT - POSTROUTING-keten.
Calico biedt beliedsopsjes wêrmei jo belied kinne tapasse oer alle keatlingen. Lit ús mei dat yn gedachten sjen nei de ferskate opsjes foar beliedskonfiguraasje dy't beskikber binne yn Calico. De nûmers yn 'e list mei opsjes hjirûnder oerienkomme mei de nûmers yn it diagram hjirboppe.
- Workload einpunt (pod) belied
- Host einpuntbelied
- ApplyOnForward opsje
- PreDNAT Belied
- Untracked Policy
Litte wy begjinne troch te sjen nei hoe't belied wurdt tapast op workload-einpunten (Kubernetes-pods of OpenStack VM's), en sjoch dan nei de beliedsopsjes foar host-einpunten.
Workload Einpunten
Einpuntbelied foar wurkdruk (1)
Dit is in opsje om jo kubernetes-pods te beskermjen. Calico stipet wurkjen mei Kubernetes NetworkPolicy, mar it leveret ek ekstra belied - Calico NetworkPolicy en GlobalNetworkPolicy. Calico makket in keatling foar elke pod (wurkbelêsting) en heakket yn 'e INPUT- en OUTPUT-keatlingen foar de wurkdruk oan' e filtertafel fan 'e FORWARD-ketting.
Host Einpunten
Host-einpuntbelied (2)
Neist CNI (container netwurk ynterface), Calico belied jout de mooglikheid om te beskermjen de host sels. Yn Calico kinne jo in host-einpunt meitsje troch in kombinaasje fan 'e hostynterface en, as nedich, poartenûmers op te jaan. Beliedshanthavenjen foar dizze entiteit wurdt berikt mei in filtertabel yn 'e INPUT- en OUTPUT-keatlingen. Sa't jo sjen kinne út it diagram, (2) se jilde foar lokale prosessen op de knooppunt / host. Dat is, as jo in belied meitsje dat jildt foar it host-einpunt, sil it gjin ynfloed hawwe op ferkear dat nei / fan jo pods giet. Mar it leveret in inkele ynterface / syntaksis foar it blokkearjen fan ferkear foar jo host en pods mei Calico-belied. Dit simplifies it proses fan it behearen fan belied foar in heterogene netwurk sterk. It konfigurearjen fan host-einpuntbelied om klusterfeiligens te ferbetterjen is in oare wichtige gebrûksgefal.
ApplyOnForward Policy (3)
De ApplyOnForward-opsje is beskikber yn Calico wrâldwide netwurkbelied om te tastean dat belied tapast wurde kin op alle ferkear dat troch it host-einpunt giet, ynklusyf ferkear dat troch de host trochstjoerd wurdt. Dit omfettet ferkear trochstjoerd nei de lokale pod of oeral oars op it netwurk. Calico fereasket dat dizze ynstelling ynskeakele is foar belied mei PreDNAT en untracked, sjoch de folgjende seksjes. Derneist kin ApplyOnForward brûkt wurde om hostferkear te kontrolearjen yn gefallen wêr't in firtuele router of software NAT wurdt brûkt.
Tink derom dat as jo itselde netwurkbelied moatte tapasse op sawol hostprosessen as pods, dan hoege jo de opsje ApplyOnForward net te brûken. Alles wat jo hoege te dwaan is in label te meitsjen foar it fereaske hostendpoint en workload endpoint (pod). Calico is tûk genôch om belied te hanthavenjen basearre op labels, nettsjinsteande it einpunttype (hostendpunt of wurkdruk).
PreDNAT-belied (4)
Yn Kubernetes kinne poarten fan tsjinst entiteit ekstern bleatsteld wurde mei de opsje NodePorts of, opsjoneel (by it brûken fan Calico), troch se te advertearjen mei de opsjes Cluster IPs of External IPs. Kube-proxy balansearret ynkommende ferkear bûn oan in tsjinst oan 'e pods fan' e oerienkommende tsjinst mei DNAT. Sjoen dit, hoe hanthavenje jo belied foar ferkear dat troch NodePorts komt? Om te soargjen dat dit belied wurdt tapast foardat it ferkear wurdt ferwurke troch DNAT (dat is in mapping tusken host: haven en oerienkommende tsjinst), Calico jout in parameter foar globalNetworkPolicy neamd "preDNAT: wier".
As pre-DNAT ynskeakele is, wurde dit belied ymplementearre yn (4) yn it diagram - yn 'e mangletabel fan' e PREROUTING-ketting - fuort foar DNAT. De gewoane folchoarder fan belied wurdt hjir net folge, om't de tapassing fan dit belied folle earder yn it ferkearsferwurkingspaad plakfynt. PreDNAT-belied respektearje lykwols de folchoarder fan tapassing ûnderinoar.
By it meitsjen fan belied mei pre-DNAT, is it wichtich om foarsichtich te wêzen oer it ferkear dat jo ferwurkje wolle en de mearderheid ôfwize kinne. Ferkear markearre as 'tastean' yn it pre-DNAT-belied sil net langer wurde kontrolearre troch it hostendpoint-belied, wylst ferkear dat it pre-DNAT-belied mislearret sil trochgean troch de oerbleaune keatlingen.
Calico hat it ferplicht makke om de applikaasje OnForward-opsje yn te skeakeljen by it brûken fan preDNAT, om't per definysje de bestimming fan it ferkear noch net selektearre is. Ferkear kin wurde rjochte op it hostproses, of it kin trochstjoerd wurde nei in pod of in oar knooppunt.
Net folge belied (5)
Netwurken en applikaasjes kinne grutte ferskillen yn gedrach hawwe. Yn guon ekstreme gefallen kinne applikaasjes in protte koarte libbensferbiningen generearje. Dit kin feroarsaakje dat conntrack (in kearnkomponint fan 'e Linux-netwurkstapel) sûnder ûnthâld rint. Tradisjoneel, om dizze soarten applikaasjes op Linux út te fieren, soene jo conntrack manuell moatte konfigurearje of útskeakelje, of iptables-regels skriuwe om conntrack te omgean. Untracked belied yn Calico is in ienfâldiger en effisjinter opsje as jo ferbinings sa rap mooglik wolle ferwurkje. Bygelyks, as jo massaal brûke of as in ekstra maatregel fan beskerming tsjin .
Lês dit (of ) foar mear ynformaasje, ynklusyf prestaasjestests mei net-tracked belied.
As jo de opsje "doNotTrack: wier" ynstelle yn Calico globalNetworkPolicy, wurdt it in **net tracked** belied en wurdt heul betiid tapast yn 'e Linux-pakketferwurkingspipeline. As jo nei it boppesteande diagram sjogge, wurdt net-tracked belied tapast yn 'e PREROUTING- en OUTPUT-keatlingen yn' e rûge tabel foardat ferbiningspoaring (conntrack) wurdt begon. As in pakket is tastien troch it net-tracked belied, is it markearre om ferbining tracking foar dat pakket út te skeakeljen. It betsjut:
- It net folge belied wurdt tapast op in per-pakket basis. D'r is gjin konsept fan ferbining (of stream). Gebrek oan ferbiningen hat ferskate wichtige gefolgen:
- As jo sawol oanfraach- as antwurdferkear tastean wolle, hawwe jo in regel nedich foar sawol ynkommende as útgeande (om't Calico gewoanlik conntrack brûkt om antwurdferkear as tastien te markearjen).
- It net folge belied wurket net foar Kubernetes-workloads (pods), om't yn dit gefal gjin manier is om de útgeande ferbining fan 'e pod te folgjen.
- NAT wurket net goed mei net-tracked pakketten (sûnt de kernel de NAT-mapping opslacht yn conntrack).
- By it trochjaan fan de regel "alles tastean" yn it net-tracked belied, wurde alle pakketten markearre as net-tracked. Dit is hast altyd net wat jo wolle, dus it is wichtich om tige selektyf te wêzen oer de pakketten dy't tastien binne troch net-tracked belied (en tastean it measte ferkear te gean troch normaal folge belied).
- Net-tracked belied wurdt tapast oan it begjin fan 'e pakketferwurkingspipeline. Dit is heul wichtich om te begripen by it meitsjen fan Calico-belied. Jo kinne in podbelied hawwe mei folchoarder: 1 en in net folge belied mei folchoarder: 1000. It sil neat skele. It Untracked-belied sil tapast wurde foar it belied foar de pod. Untracked belied respektearje de útfieringsopdracht allinich ûnder elkoar.
Om't ien fan 'e doelen fan it doNotTrack-belied is om it belied heul betiid yn 'e Linux-pakketferwurkingspipeline te hanthavenjen, makket Calico it ferplicht om de applikaasjeOnForward-opsje oan te jaan by it brûken fan doNotTrack. Ferwizend nei it pakketferwurkingsdiagram, tink derom dat it net-tracked (5) belied wurdt tapast foardat alle routing-beslissingen binne. Ferkear kin wurde rjochte op it hostproses, of it kin trochstjoerd wurde nei in pod of in oar knooppunt.
Resultaten
Wy seagen de ferskate beliedsopsjes (Host-einpunt, ApplyOnForward, preDNAT, en Untracked) yn Calico en hoe't se wurde tapast lâns it pakketferwurkingspaad. Begryp hoe't se wurkje helpt by it ûntwikkeljen fan effektyf en feilich belied. Mei Calico kinne jo in wrâldwide netwurkbelied brûke dat jildt foar in label (in groep knooppunten en pods) en belied tapasse mei ferskate parameters. Hjirmei kinne professionals yn feiligens en netwurkûntwerp maklik "alles" (einpunttypen) tagelyk beskermje mei ien beliedstaal mei Calico-belied.
Erkenning: Ik soe graach betankje и foar harren resinsje en weardefolle ynformaasje.
Boarne: www.habr.com