Mõistmine võrgu poliitikate rakendamise võimalustest Calico abil

Võrgu pistikprogramm Calico pakub laia valikut võrgu poliitikaid ühtse süntaksiga, et kaitsta hoste nii riistvaras, virtuaalmasinates kui ka podides. Need poliitikad võivad olla rakendatud namespace'i ulatuses või olla globaalseteks võrgu poliitikateks, mis kehtivad host endpoint (rakendamiseks rakendustes, mis töötavad otse hostis — host võib olla otse server või virtuaalmasin) või workload endpoint (rakendamiseks rakendustes, mis töötavad konteinerites või virtuaalmasinates, mis asuvad hostis). Calico poliitikad võimaldavad rakendada turvameetmeid erinevates paketiteedesse, kasutades selliseid parameetreid nagu preDNAT, unraracked ja applyOnForward. Nende valikute toimimise mõistmine võib aidata suurendada süsteemi turvalisust ja jõudlust. Selles artiklis selgitame nende Calico poliitikate parameetrite (preDNAT, unraracked ja applyOnForward) olemust, mis on rakendatud host endpoints'ile, rõhuga sellele, mis toimub pakettide töötlemise teedes (iptabelite ahelates).

See artikkel eeldab, et teil on arusaam Kubernetes'i ja Calico võrgu poliitikate põhimõtetest. Kui ei, siis soovitame proovida basic network policy tutorial ja host protection tutorial Calico abil, enne kui seda artiklit lugema hakkate. Ootame ka, et teil on põhiteadmised iptables Linuxist.

Calico global network policy võimaldab teil rakendada juurdepääsureeglite kogumit silte (hostide ja workloads/podide gruppide) järgi. See on väga kasulik, kui kasutate koos mitmekesiseid süsteeme — virtuaalmasinad, riistvara või Kubernetes infrastruktuuri. Lisaks saate kaitsta oma klastrit (noh) deklareeritud poliitikate kogumiga ja rakendada võrgu poliitikaid sissetulevale liiklusele (nt NodePortide või väliste IP-de kaudu).

Põhitasandi tasemel, kui Calico ühendab podi võrguga (vt allolevat diagrammi), ühendab ta selle hostiga virtuaalse Etherneti liidese (veth) kaudu. Pod'i edastatud liiklus jõuab hosti läbi selle virtuaalse liidese ja töödeldakse justkui see tuleks füüsilisest võrgu liidesest. Vaikimisi nimetab Calico neid liideseid caliXXX. Kuna liiklus tuleb läbi virtuaalse liidese, läbib see iptables'i, nagu oleks pod ühe hüppe kaugusel. Seetõttu, kui liiklus jõuab/väljub pod'ist, suunatakse see edastamise (forwarded) seisukohalt hostist.

Kubernetes'i sõlmes, kus Calico töötab, saate virtuaalse liidese (veth) vastavusse seada töökoormusega järgmiselt. Allolevas näites näete, et veth#10 (calic1cbf1ca0f8) on ühendatud cnx-manager-* calico-monitoring nimede ruumis.

[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
...

Arvestades, et Calico loob iga töökoormuse jaoks veth-liidese, kuidas ta rakendab poliitikaid? Selleks loob Calico konksud erinevatesse pakettide töötlemise tee ahelatesse, kasutades iptables'i.

Alloleval diagrammil on näidatud ahelad, mis osalevad pakettide töötlemises iptables'is (või netfilter'i alamsüsteemis). Kui pakett siseneb võrgu liidese kaudu, läbib ta esmalt PREROUTING ahela. Seejärel otsustatakse suunamine ja selle põhjal läbib pakett kas INPUT (suunatud hosti protsessidele) või FORWARD (suunatud pod'ile või teisele sõlmele võrgus). Kohalikust protsessist läbib pakett OUTPUT ahela ning seejärel POSTROUTING enne kaablisse saatmist.

Pöörake tähelepanu, et pod on samuti väline objekt (ühendatud veth'iga) iptables'i töötlemise seisukohalt. Kokkuvõttes:

• Edastatav (forwarded) liiklus (nat, marsruuditav või pod'ist välja/sisse) läbib ahelad PREROUTING — FORWARD — POSTROUTING.
• Liiklus kohalikust hosti protsessist läbib ahela PREROUTING — INPUT.
• Liiklus kohalikust hosti protsessist läbib ahela OUTPUT — POSTROUTING.

Calico pakub poliitika seadevalikuid, mille abil saab poliitikaid kohaldada kõigile ahelatele. Arvestades seda, vaatame erinevaid poliitikaseadevalikuid, mis on saadaval Calicos. Loetletud valikute numbrid vastavad ülaltoodud diagrammil olevatele numbritele.

1. Töökoha lõpp-punkti poliitika (pod)
2. Host lõpp-punkti poliitika
3. Kohaldamisvalik ApplyOnForward
4. PreDNAT poliitika
5. Untracked poliitika

Alustame sellega, kuidas poliitikaid rakendatakse töökoha lõpp-punktidele (Kubernetes pod'idele või OpenStack VM-idele), seejärel vaatame host lõpp-punktide poliitikavõimalusi.

Töökoha lõpp-punktid

Töökoha lõpp-punkti poliitika (1)

See on valik, mis kaitseb teie Kubernetes pod'e. Calico toetab Kubernetes NetworkPolicy kasutamist, kuid pakub ka täiendavaid poliitikaid - Calico NetworkPolicy ja GlobalNetworkPolicy. Calico loob iga pod'i (töökoha) jaoks ahela ning liidestab INPUT ja OUTPUT ahelatesse töökoha jaoks FILTRI tabelisse ahela FORWARD.

Host lõpp-punktid

Host lõpp-punkti poliitika (2)

Lisaks CNI (konteineri võrgu liides) poliitikale pakuvad Calico poliitikad võimalust kaitsta ka hosti. Calicos saate luua host lõpp-punkti, määrates kohaliku liidese kombinatsiooni ja, kui vajalik, ka sadamate numbrid. Selle üksuse poliitika rakendamine saavutatakse INPUT ja OUTPUT ahelate FILTER tabeli abil. Nagu diagrammil näha, rakendatakse neid (2) kohalikule protsessile node'is/hostis. See tähendab, et kui olete loonud poliitika, mis kehtib host lõpp-punktile, ei mõjuta see teie pod'ide liiklust. Kuid see tagab ühtse liidese/süntaksi liikluse blokeerimiseks teie hostile ja pod'idele Calico poliitikate abil. See lihtsustab poliitikate haldamise protsessi hübriidvõrgus. Host lõpp-punkti poliitikate seadmine klastri kaitse tugevdamiseks on veel üks oluline kasutusjuht.

Kohaldamisvalik ApplyOnForward (3)

Valik ApplyOnForward on saadaval Calico globaalsetes võrgu poliitikates, et võimaldada poliitikate rakendamist kogu host lõpp-punktist läbi käiva liikluse, sealhulgas liikluse, mis suunatakse hosti kaudu edasi. See liiklus hõlmab kohaliku pod'i suunatud või muusse võrku suunatud liiklust. Calico nõuab, et see parameeter oleks lubatud poliitikatele, mis kasutavad PreDNAT ja untracked, vt järgmisi jaotisi. Lisaks saab ApplyOnForward'i kasutada hosti liikluse jälgimiseks, kui kasutatakse virtuaalset ruuteri või tarkvaralist NAT-i.

Pange tähele, et kui peate sama võrgu poliitikat rakendama nii host-protsessidele kui ka pod'idele, ei ole teil tingimata vaja kasutada ApplyOnForward valikut. Piisab, kui loote sildi vajalikele hostendpoint ja workload endpoint (pod) jaoks. Calico on piisavalt arenenud, et rakendada poliitikat siltide alusel, sõltumata endpointi tüübist (hostendpoint või workload).

PreDNAT poliitika (4)

Kuberneteses saab teenuse portidesse suunata välisse, kasutades NodePortsi valikut või valikuliselt (kasutades Calicot) nende kuulutamisvõimalusi nagu Cluster IPs või External IPs. Kube-proxy tasakaalustab sissetulevat liiklust, mis on seotud teenusega, vastava teenuse pod'ide poole, kasutades DNAT'i. Arvestades seda, kuidas rakendada poliitikaid liiklusele, mis tuleb NodePortide kaudu? Et neid poliitikaid rakendada enne, kui liiklus on DNAT'i kaudu töödeldud (mis esindab host:port ja vastava teenuse kaardistamist), pakub Calico globalNetworkPolicy jaoks parameetrit nimega "preDNAT: true".

Kui pre-DNAT on lubatud, rakendatakse neid poliitikaid (4) diagrammil — mangle-ahela PREROUTING tabelis — vahetult enne DNAT'i. Tavalist poliitikate järjekorda (order) siin ei järgita, kuna nende poliitikate rakendamine toimub palju varem liikluse töötlemise teel. Siiski järgivad preDNAT poliitikad oma vaheline rakendusjärjekord (order).

Pre-DNAT poliitikate loomisel on oluline olla tähelepanelik liikluse suhtes, mida soovite töödelda, ja lubada enamiku liikluse tagasilükkamine. Pre-DNAT poliitikas 'allow' märgitud liiklus ei kontrollita enam hostendpoint poliitika kaudu, samas kui pre-DNAT poliitikast väljasaanud liiklus jätkab teed ülejäänud ahelate kaudu.
Calico on teinud applyOnForward valiku kasutamise preDNATiga kohustuslikuks, kuna liikluse sihtkoht ei ole veel määratud. Liiklus võib olla suunatud host-protsessile või see võib suunata pod'ile või mõnele teisele sõlmele.

Untracked poliitika (5)

Võrgud ja rakendused võivad käituda väga erinevalt. Äärmuslikel juhtudel võivad rakendused genereerida hulgaliselt lühiajalisi ühendusi. See võib põhjustada mälu nappust conntrack'is (Linuxi võrguhiire põhikomponent). Traditsiooniliselt peab Linuxis selliste rakenduste käitamiseks käsitsi seadistama või keelama conntrack'i või kirjutama iptables'e reeglid, et vältida conntrack'i. Untracked policy Calicos on lihtsam ja tõhusam võimalus, kui soovite hallata ühendusi võimalikult kiiresti. Näiteks, kui te kasutate massiivset memcache või täiendava kaitsemeetmena DDOS.

Loe seda blogipostitust (või meie tõlge) rohkem teabe saamiseks, sealhulgas jõudlustestide kohta, kui kasutatakse untracked policy't.

Kui määrate Calico globalNetworkPolicy's variandi «doNotTrack: true», siis muutub see **mitte jälgitavaks** poliitikaks ning rakendatakse Linuxi paketiprotsessi varajases etapis. Kui vaadata ülaltoodud diagrammi, siis kantakse untracked poliitikad registreerimise ja väljundite ketidesse raw tabelis enne, kui ühenduste jälgimine (conntrack) käivitub. Kui pakett on untracked poliitikaga lubatud, märgistatakse see, et keelata selle paketi ühenduse jälgimine. See tähendab:

• Untracked poliitika rakendatakse iga paketi puhul. Ühenduse (või voolu) kontseptsioon puudub. Ühenduste puudumine toob endaga kaasa mitmeid olulisi tagajärgi:
• Kui soovite lubada nii päringu kui ka vastustrafic'i, vajate reeglit nii sissetuleva kui ka väljamineva (kuna Calico kasutab tavaliselt conntrack'i, et märkida vastustranspordi lubatud).
• Untracked poliitika ei tööta Kubernetes'e töökoormuste (pod'ide) puhul, kuna sellisel juhul ei ole võimalik jälgida väljaminevat ühendust pod'ist.
• NAT ei toimi õigesti mitte jälgitavate pakettidega (kuna kernel salvestab NAT-i vaste conntrack'is).
• Kui läbida reegli 'luba kõik' kaudu untracked-poliitikas, märgistatakse kõik paketid kui mitte jälgitavad. See ei ole peaaegu kunagi see, mida soovite, seetõttu on oluline olla väga valiv untracked-poliitikaga lubatud pakettide suhtes (ja lasta suuremal osal liiklusest liikuda läbi tavapäraste jälgitavate poliitikate).
• Untracked-poliitikaid rakendatakse pakettide töötlemise konveieril alguses. See on äärmiselt oluline mõista Calico poliitikate loomisel. Teil võib olla poliitika pod'ile, mille order:1 ja untracked-poliitika order:1000. See ei oma tähtsust. Untracked-poliitika rakendatakse enne pod'i poliitikat. Untracked-poliitikad järgivad täitmise järjekorda ainult omavahel.

Kuna doNotTrack poliitika üheks eesmärgiks on rakendada poliitikat Linuxi pakettide töötlemise konveieri varases etapis, nõuab Calico doNotTrack'i kasutamisel applyOnForward valiku määratlemist. Pöörates tähelepanu pakettide töötlemise diagrammile, märkige, et untracked poliitika (5) rakendatakse enne igasuguste marsruutimisotsuste tegemist. Liiklus võib suunata host-protsessi või võib see suunata pod'i või teisele sõlmele.

Summary

Oleme arutanud erinevaid poliitikavalikuid (Host endpoint, ApplyOnForward, preDNAT ja Untracked) Calicos ja kuidas need rakendatakse pakettide töötlemise teekonnas. Nende töö põhimõtte mõistmine aitab arendada tõhusaid ja turvalisi poliitikaid. Calico abil saate kasutada globaalset võrgu poliitikat, mis rakendatakse labelile (sõlmede ja pod'ide rühmale) ning rakendada poliitikaid erinevate parametritega. See võimaldab turva- ja võrgukujunduse spetsialistidel mugavalt kaitsta „kõike” (endpoints tüübid), kasutades Calico poliitikate ühtset keelt.

Tänu: Soovin tänada Shawn Crumptoni ja Alex Pollitt nende ülevaate ja väärtusliku teabe eest.

Allikas: habr.com