Calico võrgupoliitika valikute mõistmine

Calico võrgupistikprogramm pakub laia valikut ühtse süntaksiga võrgupoliitikaid, et kaitsta riistvarahoste, virtuaalmasinaid ja kaustasid. Neid eeskirju saab rakendada nimeruumis või olla globaalsed võrgupoliitikad, mis kehtivad hosti lõpp-punkt (otse hostis töötavate rakenduste kaitsmiseks – hostiks võib olla server või virtuaalmasin) või töökoormuse lõpp-punkt (konteinerites või hostitud virtuaalmasinates töötavate rakenduste kaitsmiseks). Calico poliitikad võimaldavad teil rakendada turvameetmeid paketi tee erinevates punktides, kasutades selliseid suvandeid nagu preDNAT, unraracked ja applyOnForward. Nende valikute toimimise mõistmine võib aidata parandada teie kogu süsteemi turvalisust ja jõudlust. See artikkel selgitab nende Calico poliitikavalikute (preDNAT, unraracked ja applyOnForward) olemust, mida rakendatakse hosti lõpp-punktidele, rõhuasetusega sellele, mis juhtub pakettide töötlemise teedel (iptabelsi ahelad).

See artikkel eeldab, et teil on põhiteadmised Kubernetese ja Calico võrgupoliitikate toimimisest. Kui ei, siis soovitame proovida põhiline võrgupoliitika õpetus и hostikaitse õpetus Calico kasutamist enne selle artikli lugemist. Samuti eeldame, et teil on algteadmised tööst iptables linuxis.

Calico ülemaailmne võrgupoliitika võimaldab teil rakendada juurdepääsureeglite komplekti siltide kaupa (hostirühmadele ja töökoormustele/podidele). See on väga kasulik, kui kasutate koos heterogeenseid süsteeme – virtuaalmasinaid, otse riistvaras olevaid süsteeme või kubernetese infrastruktuuri. Lisaks saate kaitsta oma klastrit (sõlmi) deklaratiivsete poliitikate komplekti abil ja rakendada sissetulevale liiklusele võrgupoliitikaid (näiteks teenuse NodePorts või External IPs kaudu).

Põhimõtteliselt, kui Calico ühendab podi võrku (vt diagrammi allpool), ühendab see selle hostiga virtuaalse Etherneti liidese (veth) abil. Podi poolt saadetud liiklus tuleb hostile sellelt virtuaalliideselt ja seda töödeldakse samamoodi nagu füüsiliselt võrguliideselt. Vaikimisi nimetab Calico need liidesed caliXXX. Kuna liiklus tuleb läbi virtuaalse liidese, siis läbib see iptablesi nii, nagu oleks pod ühe hüppe kaugusel. Seega, kui liiklus tuleb kaubisse/aparaadist, edastatakse see hosti vaatepunktist.

Kubernetese sõlmes, kus töötab Calico, saate virtuaalse liidese (veth) töökoormusega vastendada järgmiselt. Allolevas näites näete, et veth#10 (calic1cbf1ca0f8) on ühendatud kalikoseire nimeruumis lingiga cnx-manager-*.

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

Arvestades, et Calico loob iga töökoormuse jaoks veth-liidese, kuidas see poliitikat jõustab? Selleks loob Calico iptablesi abil pakettide töötlemise tee erinevatesse ahelatesse konksud.

Allolev diagramm näitab pakettide töötlemisega seotud ahelaid iptablesis (või alamsüsteemis netfilter). Kui pakett saabub võrguliidese kaudu, läbib see esmalt ahela PREROUTING. Seejärel tehakse marsruutimisotsus ja selle põhjal läbib pakett kas INPUT-i (suunatud host-protsessidele) või FORWARD-i (suunatud poodi või mõnda teise võrgu sõlme). Kohalikus protsessis läbib pakett OUTPUT ja seejärel POSTROUTING ahela, enne kui see kaabli kaudu alla saadetakse.

Pange tähele, et pod on iptablesi töötlemise mõttes ka väline olem (ühendatud vethiga). Teeme kokkuvõtte:

• Edasisuunatud liiklus (nat, marsruudil või kaustast/kambrisse) läbib ahelaid PREROUTING - FORWARD - POSTROUTING.
• Liiklus kohalikule hostprotsessile läbib ahela PREROUTING - INPUT.
• Kohaliku hosti protsessi liiklus läbib OUTPUT - POSTROUTING ahela.

Calico pakub poliitikavalikuid, mis võimaldavad teil rakendada eeskirju kõigis kettides. Seda silmas pidades vaatame erinevaid Calicos saadaolevaid poliitika seadistamise valikuid. Allolevas valikute loendis olevad numbrid vastavad ülaltoodud diagrammi numbritele.

1. Töökoormuse lõpp-punkti (podi) poliitika
2. Hosti lõpp-punkti eeskirjad
3. ApplyOnForward valik
4. PreDNAT-i poliitika
5. Jälgimata poliitika

Alustuseks uurime, kuidas poliitikaid töökoormuse lõpp-punktidele (Kubernetese poodid või OpenStacki VM-id) rakendatakse, ja seejärel vaatame hosti lõpp-punktide poliitikavalikuid.

Töökoormuse lõpp-punktid

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

See on võimalus oma kubernetes kaunade kaitsmiseks. Calico toetab Kubernetes NetworkPolicyga töötamist, kuid pakub ka täiendavaid eeskirju – Calico NetworkPolicy ja GlobalNetworkPolicy. Calico loob iga kausta (töökoormuse) jaoks keti ja konksud SISEND ja VÄLJUNDI ahelates töökoormuse jaoks FORWARD keti filtritabeli külge.

Hosti lõpp-punktid

Hosti lõpp-punkti eeskirjad (2)

Lisaks CNI-le (konteineri võrguliides) pakuvad Calico poliitikad võimalust hosti ennast kaitsta. Calicos saate luua hosti lõpp-punkti, määrates hostiliidese ja vajaduse korral pordinumbrite kombinatsiooni. Selle olemi poliitika jõustamine saavutatakse filtritabeli abil ahelates SISEND ja VÄLJUND. Nagu diagrammil näha, (2) kehtivad need sõlme/hosti kohalikele protsessidele. See tähendab, et kui loote poliitika, mis kehtib hosti lõpp-punktile, ei mõjuta see teie kaustadesse suunduvat või sealt väljuvat liiklust. Kuid see pakub ühtset liidest/süntaksit teie hosti ja kaunade liikluse blokeerimiseks Calico poliitikate abil. See lihtsustab oluliselt heterogeense võrgu poliitikate haldamise protsessi. Teine oluline kasutusjuht on hosti lõpp-punkti poliitikate konfigureerimine klastri turvalisuse suurendamiseks.

ApplyOnForward poliitika (3)

Valik ApplyOnForward on saadaval Calico globaalses võrgupoliitikas, et võimaldada poliitikate rakendamist kogu liiklusele, mis läbib hosti lõpp-punkti, sealhulgas liiklusele, mille host edastab. See hõlmab liiklust, mis on edastatud kohalikku kausta või mujale võrgus. Calico nõuab, et see säte oleks lubatud PreDNAT-i kasutavate ja jälgimata poliitikate jaoks, vaadake järgmisi jaotisi. Lisaks saab ApplyOnForwardi kasutada hostiliikluse jälgimiseks juhtudel, kui kasutatakse virtuaalset ruuterit või tarkvara NAT-i.

Pange tähele, et kui teil on vaja rakendada sama võrgupoliitikat nii hostiprotsessidele kui ka kaustadele, ei pea te kasutama valikut ApplyOnForward. Kõik, mida pead tegema, on vajaliku hostipunkti ja töökoormuse lõpp-punkti (podi) jaoks sildi loomine. Calico on piisavalt nutikas, et jõustada siltidel põhinevaid poliitikaid, olenemata lõpp-punkti tüübist (hostpoint või töökoormus).

PreDNAT-i eeskirjad (4)

Kubernetes saab teenuseolemi porte väljastpoolt paljastada, kasutades valikut NodePorts või valikuliselt (Calico kasutamisel), reklaamides neid klastri IP-de või väliste IP-de valikute abil. Kube-puhverserver tasakaalustab DNAT abil teenusega seotud sissetuleva liikluse vastava teenuse kaustadesse. Kuidas jõustada seda arvestades NodePortide kaudu tuleva liikluse eeskirju? Tagamaks, et neid poliitikaid rakendataks enne, kui DNAT (mis on hosti: pordi ja vastava teenuse vaheline vastendamine) töötleb neid eeskirju, pakub Calico globalNetworkPolicy jaoks parameetri nimega "preDNAT: true".

Kui eel-DNAT on lubatud, rakendatakse need poliitikad diagrammi punktis (4) - ahela PREROUTING mangle tabelis - vahetult enne DNAT-i. Siin ei järgita tavapärast poliitikate järjekorda, kuna nende poliitikate rakendamine toimub liikluse töötlemise teel palju varem. PreDNAT-i poliitikad järgivad aga omavaheliste rakenduste järjekorda.

Eel-DNAT-iga poliitikate loomisel on oluline olla ettevaatlik töödeldava liikluse suhtes ja lubada enamuse tagasilükkamist. Hostendpointi poliitika ei kontrolli enam DNA-eelses poliitikas lubatuks märgitud liiklust, samas kui liiklus, mis ei vasta DNA-eelsele poliitikale, jätkub ülejäänud kettide kaudu.
Calico on muutnud preDNAT-i kasutamisel kohustuslikuks suvandi applyOnForward lubamise, kuna definitsiooni järgi pole liikluse sihtpunkti veel valitud. Liikluse saab suunata hostprotsessi või selle saab edastada taskusse või muusse sõlme.

Jälgimata poliitika (5)

Võrkude ja rakenduste käitumises võib olla suuri erinevusi. Mõnel äärmuslikul juhul võivad rakendused luua palju lühiajalisi ühendusi. See võib põhjustada conntracki (Linux'i võrgupinu põhikomponent) mälu tühjenemise. Traditsiooniliselt peate seda tüüpi rakenduste käitamiseks Linuxis conntracki käsitsi konfigureerima või keelama või kirjutama iptablesi reeglid, et conntrackist mööda minna. Jälgimata poliitika Calico's on lihtsam ja tõhusam valik, kui soovite ühendusi võimalikult kiiresti töödelda. Näiteks kui kasutate massiivset mälukaart või täiendava kaitsemeetmena DDOS.

Lugege seda blogi postitus (Või meie tõlge), et saada lisateavet, sealhulgas toimivusteste, kasutades jälgimata poliitikat.

Kui määrate Calico globalNetworkPolicy suvandi "doNotTrack: true", muutub see **jälgimata** poliitikaks ja seda rakendatakse Linuxi pakettide töötlemise konveieris väga varakult. Ülaltoodud diagrammi vaadates rakendatakse töötlemata tabeli ahelates PREROUTING ja OUTPUT enne ühenduse jälgimise (conntrack) käivitamist jälgimata poliitikad. Kui jälgimata poliitika lubab paketi, on see märgitud selle paketi ühenduse jälgimise keelamiseks. See tähendab:

• Jälgimata poliitikat rakendatakse paketipõhiselt. Ühenduse (või voolu) mõiste puudub. Ühenduste puudumisel on mitmeid olulisi tagajärgi:
• Kui soovite lubada nii päringu- kui ka vastuseliiklust, vajate reeglit nii sissetuleva kui ka väljamineva kohta (kuna Calico kasutab vastuse liikluse lubatuks märkimiseks tavaliselt conntrack).
• Jälgimata poliitika ei tööta Kubernetese töökoormuste (podide) puhul, kuna sel juhul ei ole võimalik podist väljuvat ühendust jälgida.
• NAT ei tööta õigesti jälgimata pakettidega (kuna kernel salvestab NAT-i vastenduse conntrackis).
• Kui läbite jälgimata poliitikas reegli "luba kõik", märgitakse kõik paketid jälgimata. See ei ole peaaegu alati see, mida soovite, seega on oluline olla jälgimata poliitikaga lubatud pakettide suhtes väga valiv (ja võimaldada enamikul liiklusest läbida tavalised jälgitavad poliitikad).
• Jälgimata poliitikaid rakendatakse pakettide töötlemise konveieri alguses. Seda on Calico poliitikate loomisel väga oluline mõista. Teil võib olla kausta poliitika tellimusega:1 ja jälgimata poliitika tellimusega:1000. Vahet pole. Jälgimata poliitikat rakendatakse enne podi poliitikat. Jälgimata poliitikad austavad täitmiskorraldust ainult omavahel.

Kuna üks doNotTracki poliitika eesmärke on poliitika jõustamine väga varajases Linuxi paketttöötluse konveieris, teeb Calico doNotTracki kasutamisel kohustuslikuks suvandi applyOnForward määramise. Viidates pakettide töötlemise diagrammile, pange tähele, et untracked(5) poliitikat rakendatakse enne marsruutimisotsuseid. Liikluse saab suunata hostprotsessi või selle saab edastada taskusse või muusse sõlme.

Tulemused

Vaatasime Calico erinevaid poliitikavalikuid (hosti lõpp-punkt, ApplyOnForward, preDNAT ja Untracked) ja nende rakendamist paketitöötlusteel. Nende tööpõhimõtete mõistmine aitab välja töötada tõhusaid ja ohutuid poliitikaid. Calico abil saate kasutada globaalset võrgupoliitikat, mis kehtib sildile (sõlmede ja kaustade rühm) ja rakendada erinevate parameetritega poliitikaid. See võimaldab turvalisuse ja võrgukujunduse spetsialistidel mugavalt kaitsta „kõike” (otspunktitüüpe) korraga, kasutades Calico poliitikatega ühte poliitikakeelt.

Tänuavaldus: Tahaksin tänada Sean Crampton и Alexa Pollitta ülevaate ja väärtusliku teabe eest.

Allikas: www.habr.com