Razumevanje možnosti omrežne politike s Calico

Omrežni vtičnik Calico ponuja široko paleto omrežnih pravilnikov z enotno sintakso za zaščito gostiteljev strojne opreme, virtualnih strojev in blokov. Te pravilnike je mogoče uporabiti znotraj imenskega prostora ali pa so pravilniki globalnega omrežja, ki veljajo za končna točka gostitelja (za zaščito aplikacij, ki tečejo neposredno na gostitelju – gostitelj je lahko strežnik ali virtualni stroj) oz končna točka delovne obremenitve (za zaščito aplikacij, ki se izvajajo v vsebnikih ali gostujočih virtualnih strojih). Politike Calico vam omogočajo uporabo varnostnih ukrepov na različnih točkah na poti paketa z možnostmi, kot so preDNAT, unraracked in applyOnForward. Razumevanje delovanja teh možnosti lahko pomaga izboljšati varnost in zmogljivost celotnega sistema. Ta članek pojasnjuje bistvo teh možnosti pravilnika Calico (preDNAT, unraracked in applyOnForward), ki se uporabljajo za končne točke gostitelja, s poudarkom na tem, kaj se zgodi na poteh obdelave paketov (verige iptabels).

Ta članek predvideva, da imate osnovno razumevanje delovanja omrežnih pravilnikov Kubernetes in Calico. Če ne, priporočamo, da poskusite osnovna vadnica o omrežni politiki и vadnica za zaščito gostitelja uporabite Calico, preden preberete ta članek. Prav tako pričakujemo, da boste imeli osnovno razumevanje dela iptables v linuxu.

Calico politiko globalnega omrežja omogoča uporabo nabora pravil dostopa po oznakah (za skupine gostiteljev in delovnih obremenitev/podov). To je zelo uporabno, če skupaj uporabljate heterogene sisteme – virtualne stroje, sistem neposredno na strojni opremi ali infrastrukturo kubernetes. Poleg tega lahko zaščitite svojo gručo (vozlišča) z naborom deklarativnih pravilnikov in uporabite omrežne pravilnike za dohodni promet (na primer prek storitve NodePorts ali zunanjih IP-jev).

Na temeljni ravni, ko Calico poveže pod z omrežjem (glejte spodnji diagram), ga poveže z gostiteljem z uporabo virtualnega vmesnika Ethernet (veth). Promet, ki ga pošilja enota, prihaja do gostitelja s tega virtualnega vmesnika in se obdeluje na enak način, kot če bi prišel iz fizičnega omrežnega vmesnika. Calico te vmesnike privzeto imenuje caliXXX. Ker promet prihaja prek navideznega vmesnika, poteka prek iptables, kot da bi bil pod en skok stran. Zato se promet, ko pride do/iz poda, posreduje z vidika gostitelja.

Na vozlišču Kubernetes, ki izvaja Calico, lahko preslikate navidezni vmesnik (veth) v delovno obremenitev, kot sledi. V spodnjem primeru lahko vidite, da je veth#10 (calic1cbf1ca0f8) povezan s cnx-manager-* v imenskem prostoru calico-monitoring.

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

Glede na to, da Calico ustvari vmesnik veth za vsako delovno obremenitev, kako uveljavlja politike? Za to Calico ustvari kljuke v različnih verigah poti za obdelavo paketov z uporabo iptables.

Spodnji diagram prikazuje verige, vključene v obdelavo paketov v iptables (ali podsistemu netfilter). Ko paket prispe skozi omrežni vmesnik, gre najprej skozi verigo PREROUTING. Nato se sprejme odločitev o usmerjanju in na podlagi tega gre paket bodisi skozi INPUT (usmerjen v procese gostitelja) ali FORWARD (usmerjen v pod ali drugo vozlišče v omrežju). Iz lokalnega procesa gre paket skozi verigo OUTPUT in nato POSTROUTING, preden se pošlje po kablu.

Upoštevajte, da je pod tudi zunanja entiteta (povezana z veth) v smislu obdelave iptables. Naj povzamemo:

• Posredovani promet (nat, usmerjen ali do/od enote) poteka skozi verige PRED ROUTING – NAPREJ – POSTROUTING.
• Promet do procesa lokalnega gostitelja poteka skozi verigo PREROUTING – INPUT.
• Promet iz procesa lokalnega gostitelja poteka skozi verigo OUTPUT – POSTROUTING.

Calico ponuja možnosti politik, ki vam omogočajo uporabo politik v vseh verigah. S tem v mislih si poglejmo različne možnosti konfiguracije pravilnika, ki so na voljo v Calicu. Številke na spodnjem seznamu možnosti ustrezajo številkam v zgornjem diagramu.

1. Politika končne točke delovne obremenitve (pod).
2. Politika končne točke gostitelja
3. Možnost ApplyOnForward
4. Politika PreDNAT
5. Politika brez sledenja

Začnimo z ogledom, kako se pravilniki uporabljajo za končne točke delovne obremenitve (pods Kubernetes ali OpenStack VM), nato pa si oglejmo možnosti pravilnika za končne točke gostitelja.

Končne točke delovne obremenitve

Pravilnik o končni točki delovne obremenitve (1)

To je možnost za zaščito vaših podov kubernetes. Calico podpira delo s Kubernetes NetworkPolicy, ponuja pa tudi dodatne politike - Calico NetworkPolicy in GlobalNetworkPolicy. Calico ustvari verigo za vsak pod (delovna obremenitev) in zatakne VHODNE in IZHODNE verige za delovno obremenitev v filtrirno tabelo verige NAPREJ.

Končne točke gostitelja

Politika končne točke gostitelja (2)

Poleg CNI (omrežni vmesnik vsebnika) pravilniki Calico zagotavljajo možnost zaščite samega gostitelja. V Calico lahko ustvarite končno točko gostitelja tako, da podate kombinacijo vmesnika gostitelja in, če je potrebno, številk vrat. Uveljavljanje pravilnika za to entiteto je doseženo z uporabo filtrirne tabele v verigah INPUT in OUTPUT. Kot lahko vidite iz diagrama, (2) veljajo za lokalne procese na vozlišču/gostitelju. To pomeni, da če ustvarite pravilnik, ki velja za končno točko gostitelja, to ne bo vplivalo na promet, ki gre v/iz vaših podov. Zagotavlja pa en sam vmesnik/skladnjo za blokiranje prometa za vašega gostitelja in enote s pravilniki Calico. To močno poenostavi postopek upravljanja politik za heterogeno omrežje. Konfiguriranje pravilnikov končne točke gostitelja za izboljšanje varnosti gruče je še en pomemben primer uporabe.

Pravilnik ApplyOnForward (3)

Možnost ApplyOnForward je na voljo v pravilniku globalnega omrežja Calico, da omogoči uporabo pravilnikov za ves promet, ki poteka skozi končno točko gostitelja, vključno s prometom, ki ga bo posredoval gostitelj. To vključuje promet, posredovan lokalnemu bloku ali kamor koli drugje v omrežju. Calico zahteva, da je ta nastavitev omogočena za pravilnike, ki uporabljajo PreDNAT in nesledijo, glejte naslednje razdelke. Poleg tega se lahko ApplyOnForward uporablja za spremljanje prometa gostitelja v primerih, ko se uporablja virtualni usmerjevalnik ali programska oprema NAT.

Upoštevajte, da vam ni treba uporabiti možnosti ApplyOnForward, če morate isti omrežni pravilnik uporabiti tako za gostiteljske procese kot za bloke. Vse kar morate storiti je, da ustvarite oznako za zahtevano končno točko gostitelja in končno točko delovne obremenitve (pod). Calico je dovolj pameten, da uveljavi pravilnik na podlagi oznak, ne glede na vrsto končne točke (gostiteljska točka ali delovna obremenitev).

Politika PreDNAT (4)

V Kubernetesu je mogoče vrata storitvene entitete izpostaviti navzven z možnostjo NodePorts ali, izbirno (pri uporabi Calico), z oglaševanjem z uporabo možnosti IP-jev gruče ali Zunanjih IP-jev. Kube-proxy uravnava dohodni promet, vezan na storitev, na pode ustrezne storitve z uporabo DNAT. Glede na to, kako uveljavljate politike za promet, ki prihaja prek NodePorts? Za zagotovitev, da se ti pravilniki uporabijo, preden promet obdela DNAT (ki je preslikava med gostitelj:vrata in ustrezno storitvijo), Calico zagotavlja parameter za globalNetworkPolicy, imenovan "preDNAT: true".

Ko je pre-DNAT omogočen, se ti pravilniki implementirajo v (4) v diagramu - v razpredelnici verige PREROUTING - tik pred DNAT. Tu se ne upošteva običajni vrstni red pravilnikov, saj se uporaba teh pravilnikov pojavi veliko prej na poti obdelave prometa. Vendar politike preDNAT upoštevajo vrstni red uporabe med seboj.

Pri ustvarjanju pravilnikov s pre-DNAT je pomembno, da ste previdni glede prometa, ki ga želite obdelati, in dovolite, da se večina zavrne. Promet, ki je v pravilniku pred DNAT označen kot 'dovoljeno', ne bo več preverjan s pravilnikom o gostiteljski točki, medtem ko se bo promet, ki ne izpolnjuje pravilnika pred DNAT, nadaljeval skozi preostale verige.
Calico je omogočil obvezno omogočanje možnosti applyOnForward pri uporabi preDNAT, saj cilj prometa po definiciji še ni bil izbran. Promet se lahko usmeri v gostiteljski proces ali pa se posreduje podu ali drugemu vozlišču.

Politika brez sledenja (5)

Omrežja in aplikacije imajo lahko velike razlike v obnašanju. V nekaterih skrajnih primerih lahko aplikacije ustvarijo veliko kratkotrajnih povezav. To lahko povzroči, da conntrack (jedrna komponenta omrežnega sklada Linux) zmanjka pomnilnika. Običajno bi morali za zagon teh vrst aplikacij v Linuxu ročno konfigurirati ali onemogočiti conntrack ali napisati pravila iptables, da bi zaobšli conntrack. Politika brez sledenja v Calicu je preprostejša in učinkovitejša možnost, če želite povezave obdelati čim hitreje. Na primer, če uporabljate masivno memcache ali kot dodaten ukrep zaščite pred DDOS.

Preberi to blog post (Ali naš prevod) za več informacij, vključno s preizkusi zmogljivosti z uporabo nesledenega pravilnika.

Ko nastavite možnost »doNotTrack: true« v Calico globalNetworkPolicy, postane pravilnik **nesleden** in se uporabi zelo zgodaj v cevovodu za obdelavo paketov Linux. Če pogledamo zgornji diagram, se nesledeni pravilniki uporabijo v verigah PREROUTING in OUTPUT v neobdelani tabeli, preden se začne sledenje povezavi (conntrack). Ko je paket dovoljen s pravilnikom o nesledenju, je označen, da onemogoči sledenje povezavi za ta paket. To pomeni:

• Politika brez sledenja se uporablja za posamezen paket. Ni koncepta povezave (ali toka). Pomanjkanje povezav ima več pomembnih posledic:
• Če želite dovoliti promet z zahtevami in odzivi, potrebujete pravilo tako za dohodni kot za izhodni promet (ker Calico običajno uporablja conntrack, da označi promet za odzive kot dovoljen).
• Politika brez sledenja ne deluje za delovne obremenitve Kubernetes (pods), ker v tem primeru ni mogoče slediti odhodni povezavi iz sklopa.
• NAT ne deluje pravilno s paketi, ki jim ni sledi (ker jedro shrani preslikavo NAT v conntrack).
• Pri prehodu skozi pravilo »dovoli vse« v nesledenem pravilniku bodo vsi paketi označeni kot nesledeni. To skoraj vedno ni tisto, kar želite, zato je pomembno, da ste zelo izbirčni glede paketov, ki jih dovoljujejo nesledeni pravilniki (in omogočite večini prometa, da gre skozi običajne sledene pravilnike).
• Nesledeni pravilniki se uporabijo na samem začetku cevovoda za obdelavo paketov. To je zelo pomembno razumeti pri ustvarjanju pravilnikov Calico. Lahko imate politiko pod z order:1 in politiko brez sledenja z order:1000. Ne bo pomembno. Politika Nesledeno bo uporabljena pred politiko za sklop. Nesledeni pravilniki upoštevajo izvršilni vrstni red samo med seboj.

Ker je eden od namenov pravilnika doNotTrack uveljavitev pravilnika zelo zgodaj v cevovodu za obdelavo paketov Linux, je Calico določil obvezno določitev možnosti applyOnForward pri uporabi doNotTrack. Glede na diagram obdelave paketov upoštevajte, da se pred kakršnimi koli odločitvami o usmerjanju uporabi pravilnik o nesledenju (5). Promet se lahko usmeri v gostiteljski proces ali pa se posreduje podu ali drugemu vozlišču.

Rezultati

Ogledali smo si različne možnosti pravilnika (končna točka gostitelja, ApplyOnForward, preDNAT in Untracked) v Calicu in kako se uporabljajo na poti obdelave paketov. Razumevanje njihovega delovanja pomaga pri razvoju učinkovitih in varnih politik. S Calico lahko uporabite globalno omrežno politiko, ki velja za oznako (skupino vozlišč in podov), in uporabite politike z različnimi parametri. To strokovnjakom za varnost in načrtovanje omrežja omogoča priročno zaščito "vsega" (vrste končnih točk) naenkrat z uporabo enega samega jezika pravilnika s pravilniki Calico.

Zahvala: Rad bi se zahvalil Sean Crampton и Alexa Pollitta za njihov pregled in dragocene informacije.

Vir: www.habr.com