Calicoga võrgu poliitikate rakendamise variantide mõistmine.

Calico võrgulisand pakub laialdast poliitika komplekti ühtse süntaksiga, et kaitsta hoste, virtuaalmasinaid ja pod'e. Need poliitikad võivad olla rakendatavad nimede ruumi tasandil või olla globaalsete võrgupoliitikatena, mis rakenduvad host endpoint (rakenduste kaitsmiseks, mis töötavad otse hostis — host võib olla kas server või virtuaalmasin) või workload endpoint (rakenduste kaitsmiseks, mis töötavad konteinerites või virtuaalmasinates, mis on hostis. Calico poliitikad võimaldavad rakendada turvameetmeid erinevates paketiteedepunktides, kasutades selliseid parameetreid nagu preDNAT, unraracked ja applyOnForward. Nende valikute toimimise mõistmine võib aidata suurendada süsteemi üldist turvalisust ja jõudlust. Käesolevas artiklis selgitatakse Calico poliitikate (preDNAT, unraracked ja applyOnForward) olemust, mis rakendatakse host endpointidele, keskendudes sellele, mis juhtub pakettide töötlemise teedes (iptabelite ahelates).

Käesolev artikkel eeldab, et teil on teadmised Kubernetes ja Calico võrgupoliitikate põhitõdedest. Kui ei, siis soovitame proovida alusvõrgu poliitika õpik ja hosti kaitse õpik kasutades Calicot, enne selle artikli lugemist. Eeldame samuti, et teil on põhiteadmised iptables Linuxi kohta.

Calico globaalne võrgu poliitika võimaldab teil rakendada juurdepääsureeglite kogumit etikettide (hostide ja workloads/podide rühmade) järgi. See on väga kasulik, kui kasutate koos erinevaid süsteeme — virtuaalmasinad, otse raual töötav süsteem või Kubernetes infrastruktuur. Samuti saate kaitsta oma klastrit (noode) deklaratiivsete poliitikate kogumiga ja rakendada võrgu poliitikaid sissetulevale liiklusele (nt läbi NodePorts või väliste IP-de teenuse).

Aluselt, kui Calico ühendab pod'i võrku (vt allolevat diagrammi), ühendab ta selle hostiga virtuaalse Etherneti liidese (veth) kaudu. Pod'i edastatud liiklus jõuab hosti sellel virtuaalsel liidesel ja töödeldakse nagu füüsiliselt võrguliideselt tulnud liiklus. Vaikimisi nimetab Calico neid liideseid caliXXX. Kuna liiklus siseneb virtuaalse liidese kaudu, läbib see iptables, nagu oleks pod ühe hop'i kaugusel. Seetõttu, kui liiklus jõuab/üles tõuseb pod'ist, suunatakse see hosti seisukohalt edasi.

Kubernetes'i sõlmel, kus Calico on käimas, saate virtuaalse liidese (veth) vastandada töökoormusele järgmiselt. Allolevas näites näete, et veth#10 (calic1cbf1ca0f8) on ühendatud cnx-manager- * calico-monitoring namespace'is.

[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 see poliitikaid rakendab? Selleks loob Calico konksud mitmetesse pakettide töötlemise ketidesse, kasutades iptables'i.

Alloleval diagrammil on näidatud chainid, mis osalevad pakettide töötlemises iptables'is (või netfilter'i süsteemis). Kui paketid tulevad läbi võrguliidese, läbivad need esmalt PREROUTING ketti. Seejärel langetatakse marsruutimise otsus, ning selle alusel läbib paket kas INPUT ketti (suunatud hosti protsessidele) või FORWARD ketti (suunatud pod'ile või teisele nodile võrgus). Kohalikku protsessi minnes läbib pakett OUTPUT ketti ja seejärel POSTROUTING'i enne edastamist kaabli kaudu.

Pange tähele, et pod on samuti väline objekt (ühendatud veth'iga) iptables'i töötlemise jaoks. Kokkuvõtteks:

• Edastatav (forwarded) liiklus (nat, marsruutimisvõime või pod'i sisse/ välja) läbib PREROUTING — FORWARD — POSTROUTING ketid.
• Kohalikku hosti protsessile suunatud liiklus läbib PREROUTING — INPUT ketti.
• Kohalikust hosti protsessist tulenev liiklus läbib OUTPUT — POSTROUTING ketti.

Calico pakub poliitikate valikuid, mille abil saab rakendada poliitikaid kõigile ahelatele. Arvesse võttes seda, vaatame erinevaid poliitikate seadistamise võimalusi, mis on saadaval Calicos. Allpool olevate valikute numbrid vastavad ülaltoodud diagrammi numbritele.

1. Töökoha lõpp-punkti poliitika
2. Gost lõpp-punkti poliitika
3. Valik ApplyOnForward
4. PreDNAT poliitika
5. Untracked poliitika

Alustame sellest, kuidas poliitikaid rakendatakse töökoha lõpp-punktidele (Kubernetes pod’idele või OpenStack VM-idele), seejärel vaatame host-lõpp-punktide poliitika valikuid.

Töökoha lõpp-punktid

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

See on valik teie Kubernetes pod'ide kaitsmiseks. Calico toetab Kubernetes NetworkPolicy'd, kuid see pakub ka täiendavaid poliitikaid — Calico NetworkPolicy ja GlobalNetworkPolicy. Calico loob iga pod'i (töökoha) jaoks ahela ja ühendab töökoha ahelad INPUT ja OUTPUT ahelate filtri tabelisse.

Gost lõpp-punktid

Gost lõpp-punkti poliitika (2)

Lisaks CNI-le (konteineri võrgu liides) pakuvad Calico poliitikad võimalust kaitsta otse hosti. Calicos saate luua hosti lõpp-punkti, määrates hosti liidese ning vajadusel ka pordi numbrid. Nende poliitikate rakendamine selle üksuse jaoks toimub FILTER tabeli abil INPUT ja OUTPUT ahelates. Nagu diagrammilt näha, (2) rakendatakse neid kohalikest protsessidest sõlmes/hostis. See tähendab, et kui loote poliitika, mis rakendub hosti lõpp-punktile, ei mõjuta see liiklust, mis suundub teie pod'ide poole või sealt ära. Kuid selle abil tagatakse ühtne liides/süntaks liikluse blokeerimise jaoks teie hostile ja pod'idele Calico poliitikate abil. See lihtsustab poliitikate haldamise protsessi erinevas võrgus. Host lõpp-punktide poliitikate seadistamine klastrikaitse tugevdamiseks on veel üks oluline kasutusjuht.

ApplyOnForward Policy (3)

ApplyOnForward valik on saadaval Calico globaalsete võrgupoliitikate puhul, et võimaldada poliitikate rakendamist kogu liiklusele, mis läbib hosti lõpp-punkti, sealhulgas liiklusele, mis suunatakse hosti (edastatakse). See liiklus hõlmab ka liiklust, mis edastatakse kohalikku podi või mõnda muud punkti võrgus. Calico nõuab, et see valik oleks aktiveeritud poliitikate puhul, mis kasutavad PreDNAT ja untracked, vt järgmisi jaotisi. Lisaks saab ApplyOnForward'i kasutada hosti liikluse jälgimiseks, kui kasutatakse virtuaalset ruuterit või tarkvara NAT-i.

Märkusena, kui on vaja rakendada sama võrgupoliitikat nii hosti protsesside kui ka pod'ide jaoks, ei ole sul vaja kasutada ApplyOnForward valikut. Piisab, kui loo soovitud hosti lõpp-punkti ja töökoha lõpp-punkti (pod) jaoks label. Calico on piisavalt nutikas, et rakendada poliitikat põhjal labels'i, sõltumata lõpp-punkti tüübist (hostendpoint või workload).

PreDNAT poliitika (4)

Kubernetesis võivad teenuse üksuste pordid väljast suunata, kasutades NodePort'i valikut või, valikuliselt (kui kasutatakse Calicot), määrates neid Cluster IP-de või External IP-de kaudu. Kube-proxy tasakaalustab teenusele suunatud sissetulevat liiklust, suunates selle vastavatesse pod'idesse, kasutades DNAT-i. Arvestades seda, kuidas rakendada poliitikaid NodePortide kaudu saabuvale liiklusele? Et need poliitikad kehtiksid enne, kui liiklus töödeldakse DNAT-i (mis on hosti ja pordi ning vastava teenuse vastavustähis), pakub Calico globalNetworkPolicy jaoks parameetrit nimega „preDNAT: true”.

Kui pre-DNAT on lubatud, rakendatakse neid poliitikaid (4) diagrammil — PREROUTINGi mangle-ahelas — vahetult enne DNAT-i. Tavalist poliitikate järjekorda (order) siin ei järgita, kuna nende poliitikate rakendamine toimub liikluse töötlemise teel palju varem. Sellegipoolest järgivad preDNAT poliitikad üksteise vahel rakendamise järjekorda (order).

Pre-DNAT poliitika loomisel on tähtis pöörata tähelepanu sellele, millist liiklust soovite töödelda, ja lasta enamiku liiklusest tagasi lükata. Pre-DNAT poliitikas märgitud liiklus, mis on ‘lubatud’, ei kontrollita enam hostendpoint poliitika järgi, samas kui liiklus, mis ebaõnnestub pre-DNAT poliitika läbimisel, jätkab teed ülejäänud ahelate kaudu.
Calico on teinud nõutuks applyOnForward valiku lubamise preDNATi kasutamisel, kuna sihtkoht on liikluse määratlemisel veel valimata. Liiklus võib suunata host-protsessi, või see võib suunata podi või teisele sõlmele.

Untracked Policy (5)

Võrgud ja rakendused võivad käituda väga erinevalt. Mõnes äärmuslikus olukorras võivad rakendused genereerida hulgaliselt lühikese kestusega ühendusi. See võib põhjustada mälupuudust conntrackis (Linuxi võrgualuse peamine komponent). Traditsiooniliselt nõuab selliste rakenduste käitamine Linuxis conntracki käsitsi seadistamist või väljalülitamist, või iptablesi reeglite kirjutamist conntracki ümbersõitmiseks. Untracked policy Calicos on lihtsam ja efektiivsem valik, kui soovite käsitleda ühendusi maksimaalselt kiiresti. Näiteks kui kasutate massiivset memcache või täiendava kaitsemeetmena DDOS.

Lugege seda blogipostitust (või meie tõlgete kohta) täiendavateks üksikasjadeks, sealhulgas jõudlustestid untracked policy kasutamisel.

Kui määrate "doNotTrack: true" valiku Calico globalNetworkPolicy-s, muutub see **mitte jälgitavaks** poliitikaks ja rakendatakse Linuxi pakettide töötlemise torus väga varakult. Kui vaadata ülaltoodud diagrammi, rakendatakse jälgimata poliitikaid PREROUTING ja OUTPUT ahelates raw tabelis enne, kui ühenduste jälgimine (conntrack) käivitatakse. Kui pakett on jälgimata poliitika poolt lubatud, märgistatakse see, et keelata selle paketi ühenduse jälgimine. See tähendab:

• Jälgimata poliitika rakendatakse iga paketi jaoks. Ühenduse (või voolu) mõistet ei ole. Ühenduste puudumine toob kaasa mitmeid olulisi tagajärgi:
• Kui soovite lubada nii päringutrafiku kui ka vastustranspordi, peate looma reegli nii sissetuleva kui ka väljuva (kuna Calico kasutab tavaliselt conntracki, et märkida vastuträfik lubatud).
• Jälgimata poliitika ei tööta Kubernetes töökoormuse (pod'ide) jaoks, kuna selles olukorras pole võimalik jälgida pod'ist väljuvat ühendust.
• NAT ei tööta õigesti jälgimata pakettide puhul (kuna kernal salvestab NAT-i vastavuse conntrackis).
• Kui untracked-poliitika kaudu käib reegel "luba kõik", siis kõik paketid märgitakse kui mittejälgitavad. See pole tavaliselt see, mida vajate, seega on oluline olla väga valiv lubatud paketide osas untracked-poliitikate puhul (ja lasta suuremal osal liiklusest läbi minna tavapäraste jälgitavate poliitikate).
• Untracked-poliitikad kehtivad pakettide töötlemise toru alguses. See on väga oluline mõista Calico poliitikate loomisel. Teil võib olla pod'i poliitika, mille järjekord on 1, ja untracked-poliitika, mille järjekord on 1000. See ei oma tähtsust. Untracked-poliitika rakendatakse enne pod'i poliitikat. Untracked-poliitikad järgivad järjekorda ainult omavahel.

Kuna policy doNotTrack eesmärk on sundida poliitika rakendamist Linuxi pakettide töötlemise toru varases etapis, teeb Calico doNotTrack kasutamisel applyOnForward valiku määramise kohustuslikuks. Vaadates paketitöötlemise diagrammi, märkage, et untracked-poliitika (5) rakendatakse enne rajaotsuste tegemist. Liiklus võib suunata host-protsessile või suunata pod'i või teise sõlme.

Kokkuvõte

Oleme uurinud erinevaid poliitikavõimalusi (Host endpoint, ApplyOnForward, preDNAT ja Untracked) Calicos ja kuidas need pakettide töötlemise teekonnas rakenduvad. Nende toimimise mõistmine aitab välja töötada tõhusad ja turvalised poliitikad. Calico abil saate kasutada globaalset võrgupoliitikat, mis rakendub silti (node'ide ja pod'ide rühmale) ning rakendada poliitikaid erinevate parameetritega. See võimaldab turbe- ja võrguarhitektuuri spetsialistidel mugavalt kaitsta kohe kõike (endpoints tüübid), kasutades ühtset poliitikakeelt Calico poliitikatega.

Tänu: Soovisin tänada Sean Crumptoni ja Alex Pollitti nende ülevaate ja väärtusliku teabe eest.

Allikas: habr.com