Calico sareko pluginak sare-politika sorta zabala eskaintzen du sintaxi bateratuarekin hardware-ostalariak, makina birtualak eta podak babesteko. Politika hauek izen-espazio baten barruan aplika daitezke edo sare-politika globalak izan daitezke
Artikulu honek suposatzen du Kubernetes eta Calico sareko politikak nola funtzionatzen duten oinarrizko ulertzen duzula. Hala ez bada, probatzea gomendatzen dugu
Calico
Oinarrizko mailan, Calicok pod bat sarera konektatzen duenean (ikus beheko diagrama), ostalariarekin konektatzen du Ethernet interfaze birtual bat (veth) erabiliz. Podak bidalitako trafikoa interfaze birtual honetatik iristen da ostalarira eta sare fisikoko interfaze batetik etorriko balitz bezala prozesatzen da. Lehenespenez, Calicok interfaze hauei caliXXX izena ematen die. Trafikoa interfaze birtualetik datorrenez, iptables bidez pasatzen da poda salto batera egongo balitz bezala. Hori dela eta, trafikoa pod batera/etortzen denean, ostalariaren ikuspuntutik birbidaltzen da.
Calico exekutatzen duen Kubernetes nodo batean, interfaze birtual bat (veth) lan-karga batera mapa dezakezu honela. Beheko adibidean, veth#10 (calic1cbf1ca0f8) cnx-manager-*-ra konektatuta dagoela ikus dezakezu calico-monitoring izen-eremuan.
[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
...
Calicok lan-karga bakoitzerako beth interfaze bat sortzen duela kontuan hartuta, nola betetzen ditu politikak? Horretarako, Calicok paketeak prozesatzeko bideko hainbat kateetan amuak sortzen ditu iptables erabiliz.
Beheko diagramak iptables-en (edo netfilter azpisisteman) paketeen prozesamenduan parte hartzen duten kateak erakusten ditu. Pakete bat sareko interfaze batetik iristen denean, lehenik PREROUTING katetik pasatzen da. Gero bideratze-erabakia hartzen da, eta, horren arabera, paketea INPUT (ostalari prozesuetara zuzendua) edo FORWARD (sareko pod batera edo beste nodo batera zuzenduta) pasatzen da. Prozesu lokaletik, paketea OUTPUT eta gero POSTROUTING katetik pasatzen da kabletik behera bidali aurretik.
Kontuan izan poda kanpoko entitate bat dela (veth-arekin konektatuta) iptables prozesatzeari dagokionez. Laburtu dezagun:
- Birbidaltzen den trafikoa (naturismoa, bideratua edo pod batetik/era) PREROUTING - FORWARD - POSTROUTING kateetatik igarotzen da.
- Tokiko ostalari prozesurako trafikoa PREROUTING - INPUT katetik pasatzen da.
- Tokiko ostalari prozesuko trafikoa OUTPUT - POSTROUTING katetik pasatzen da.
Calicok politika-aukerak eskaintzen ditu, kate guztietan politikak aplikatzeko aukera ematen dutenak. Hori kontuan izanda, ikus ditzagun Calico-n dauden politika konfiguratzeko aukera desberdinak. Beheko aukeren zerrendako zenbakiak goiko diagramako zenbakiekin bat datoz.
- Lan-kargaren amaierako (pod) politika
- Ostalari amaierako politika
- ApplyOnForward aukera
- PreDNAT politika
- Jarraitu gabeko politika
Has gaitezen politikak lan-kargaren amaiera-puntuetan (Kubernetes pods edo OpenStack VM-ak) nola aplikatzen diren aztertzen, eta, ondoren, ikus gaitezen ostalariaren amaiera-puntuen politika-aukerak.
Lan-kargaren amaiera-puntuak
Lan-kargaren amaierako politika (1)
Hau zure kubernetes lekak babesteko aukera bat da. Calicok Kubernetes NetworkPolicy-rekin lan egitea onartzen du, baina politika osagarriak ere eskaintzen ditu: Calico NetworkPolicy eta GlobalNetworkPolicy. Calicok kate bat sortzen du pod (lan-karga) bakoitzeko eta INPUT eta OUTPUT kateetako kate bat sortzen du FORWARD katearen iragazkien taulara.
Ostalari amaierako puntuak
Ostalari amaierako politika (2)
CNI (edukiontzi-sare-interfazea) gain, Calico-ren politikek ostalaria bera babesteko gaitasuna eskaintzen dute. Calico-n, ostalariaren amaiera-puntu bat sor dezakezu ostalari-interfazearen eta, behar izanez gero, ataka-zenbakien konbinazio bat zehaztuz. Entitate honen politika betearaztea INPUT eta OUTPUT kateetako iragazki-taula bat erabiliz lortzen da. Diagraman ikus dezakezun bezala, (2) nodo/ostalariaren prozesu lokaletan aplikatzen dira. Hau da, ostalariaren amaiera-puntuan aplikatzen den politika bat sortzen baduzu, ez du eragingo zure ontzietara/tik datorren trafikoa. Baina interfaze/sintaxi bakarra eskaintzen du zure ostalariaren eta lekak Calico politikak erabiliz trafikoa blokeatzeko. Horrek asko errazten du sare heterogeneo baterako politikak kudeatzeko prozesua. Ostalari amaierako politikak konfiguratzea klusterren segurtasuna hobetzeko beste erabilera kasu garrantzitsu bat da.
ApplyOnForward politika (3)
ApplyOnForward aukera Calicoko sare globalaren politikan dago erabilgarri, ostalariaren amaiera-puntutik igarotzen den trafiko guztiari politikak aplikatzea ahalbidetzeko, ostalariak birbidaliko duen trafikoa barne. Honen barruan sartzen da tokiko podra edo sareko beste edozein tokitara birbidaltzen den trafikoa. Calicok ezarpen hau gaituta egotea eskatzen du PreDNAT erabiltzen duten gidalerroetarako eta jarraipena egin gabe, ikusi hurrengo atalak. Horrez gain, ApplyOnForward ostalariaren trafikoa kontrolatzeko erabil daiteke bideratzaile birtual edo software NAT erabiltzen den kasuetan.
Kontuan izan sare-politika bera ostalari-prozesuetan zein podetan aplikatu behar baduzu, ez duzula ApplyOnForward aukera erabili behar. Behar duzun ostalari-puntuaren eta lan-kargaren amaierako (pod) etiketa bat sortzea besterik ez duzu behar. Calico nahikoa adimentsu da etiketetan oinarritutako politika betearazteko, amaiera-puntu mota edozein dela ere (ostalari-puntua edo lan-karga).
PreDNAT politika (4)
Kubernetesen, zerbitzu-entitateen atakak kanpotik agerian egon daitezke NodePorts aukera erabiliz edo, aukeran (Calico erabiltzen denean), Cluster IPak edo Kanpoko IPak aukerak erabiliz iragarkiz. Kube-proxy-k zerbitzu bati loturiko sarrerako trafikoa orekatzen du dagokion zerbitzuaren podetara DNAT erabiliz. Hori ikusita, nola ezarri NodePorts bidez datorren trafikorako politikak? Politika hauek DNAT-k trafikoa prozesatu baino lehen aplikatzen direla ziurtatzeko (hau da ostalari:portuaren eta dagokion zerbitzuaren arteko mapaketa bat), Calicok "preDNAT: true" izeneko parametro bat eskaintzen du GlobalNetworkPolicy-rako.
Pre-DNAT gaituta dagoenean, politika hauek (4) diagraman inplementatzen dira - PREROUTING kateko mangle taulan - DNATren aurretik berehala. Hemen ez da politiken ohiko ordena jarraitzen, politika horien aplikazioa askoz lehenago gertatzen baita trafikoa prozesatzeko bidean. Hala ere, preDNAT politikek euren artean aplikatzeko ordena errespetatzen dute.
Pre-DNAT-ekin politikak sortzean, garrantzitsua da prozesatu nahi duzun trafikoarekin kontuz ibili eta gehiengoa baztertu dadin. Aurretik DNAT gidalerroan "baimendu" gisa markatutako trafikoa ez da ostalari-puntuaren politikak egiaztatuko, eta DNAT aurreko politikan huts egiten duen trafikoak gainerako kateetan zehar jarraituko du.
Calicok derrigorrezkoa egin du applyOnForward aukera gaitzea preDNAT erabiltzean, definizioz oraindik ez baita hautatu trafikoaren helmuga. Trafikoa ostalariaren prozesura bideratu daiteke, edo pod batera edo beste nodo batera birbidal daiteke.
Jarraitu gabeko politika (5)
Sareek eta aplikazioek portaeran alde handiak izan ditzakete. Muturreko kasu batzuetan, aplikazioek iraupen laburreko konexio asko sor ditzakete. Honek conntrack (Linux sareko pilaren oinarrizko osagaia) memoria agortzea eragin dezake. Tradizionalki, Linux-en aplikazio mota hauek exekutatzeko, eskuz konfiguratu edo desgaitu beharko zenituzke conntrack, edo iptables arauak idatzi conntrack saihesteko. Calicon jarraitu gabeko politika aukera sinpleagoa eta eraginkorragoa da konexioak ahalik eta azkarren prozesatu nahi badituzu. Adibidez, masiboa erabiltzen baduzu
Irakurri hau
Calico globalNetworkPolicy-n "doNotTrack: true" aukera ezartzen duzunean, **jarraipenik gabeko** politika bihurtzen da eta oso goiz aplikatzen da Linux paketeak prozesatzeko kanalizazioan. Goiko diagrama ikusita, jarraipenik gabeko politikak taula gordineko PREROUTING eta OUTPUT kateetan aplikatzen dira konexioen jarraipena (conntrack) hasi aurretik. Jarraitu gabeko politikak pakete bat onartzen duenean, pakete horren konexioen jarraipena desgaitzeko markatuta dago. Esan nahi du:
- Jarraitu gabeko politika pakete bakoitzeko aplikatzen da. Ez dago konexio (edo fluxu) kontzepturik. Konexiorik ezak hainbat ondorio garrantzitsu ditu:
- Eskaeren eta erantzunen trafikoa baimendu nahi baduzu, sarrerako eta irteerako arau bat behar duzu (Calicok normalean conntrack erabiltzen baitu erantzunen trafikoa baimendu gisa markatzeko).
- Jarraitu gabeko gidalerroak ez du funtzionatzen Kubernetesen lan-kargak (pods), kasu honetan ez baitago podetik irteerako konexioaren jarraipena egiteko modurik.
- NATek ez du behar bezala funtzionatzen jarraitu gabeko paketeekin (nukleoak NAT mapaketa conntrack-en gordetzen baitu).
- Jarraitu gabeko gidalerroko "onartu guztiak" araua igarotzean, pakete guztiak jarraitu gabeko gisa markatuko dira. Hau ia beti ez da nahi duzuna, beraz, garrantzitsua da jarraipenik gabeko politikek onartzen dituzten paketeei buruz oso hautakorra izatea (eta trafiko gehienari jarraipeneko politika arruntetatik igarotzea baimentzea).
- Jarraitu gabeko politika paketeak prozesatzeko kanalaren hasieran aplikatzen dira. Hau oso garrantzitsua da ulertzea Calico politikak sortzean. Pod politika bat izan dezakezu order:1-rekin eta jarraipena gabeko politika bat order:1000-rekin. Berdin du. Jarraitu gabeko gidalerroa pod-aren gidalerroaren aurretik aplikatuko da. Jarraitu gabeko politikek euren artean soilik errespetatzen dute exekuzio-agindua.
DoNotTrack politikaren helburuetako bat Linux paketeen prozesatzeko kanalizazioan politika oso goiz betearaztea denez, Calicok derrigorrezkoa da applyOnForward aukera zehaztea doNotTrack erabiltzean. Paketeen prozesatzeko diagramari erreferentzia eginez, kontuan izan jarraitu gabeko (5) politika bideratze-erabakien aurretik aplikatzen dela. Trafikoa ostalariaren prozesura bideratu daiteke, edo pod batera edo beste nodo batera birbidal daiteke.
Emaitzak
Calicoko politika-aukera desberdinak (Ostalari amaierako puntua, ApplyOnForward, preDNAT eta Untracked) aztertu ditugu eta paketeen prozesatzeko bidean nola aplikatzen diren aztertu dugu. Nola funtzionatzen duten ulertzeak politika eraginkor eta seguruak garatzen laguntzen du. Calico-rekin etiketa bati aplikatzen zaion sare-politika global bat erabil dezakezu (nodo eta pod talde bat) eta hainbat parametro dituzten politikak aplika ditzakezu. Horri esker, segurtasun- eta sare-diseinuko profesionalek "dena" (amaiera-puntu motak) modu egokian babestu dezakete aldi berean Calico politikekin politika-hizkuntza bakarra erabiliz.
Aitorpena: eskerrak eman nahi nituzke
Iturria: www.habr.com