Înțelegerea opțiunilor de aplicare a politicilor de rețea cu Calico

Pluginul de rețea Calico oferă un set larg de politici de rețea cu o sintaxă unificată pentru a proteja gazdele pe hardware, mașinile virtuale și pod-urile. Aceste politici pot fi aplicate la nivel de namespace sau pot fi politici de rețea globale, aplicabile la endpoint de gazdă (pentru protejarea aplicațiilor care rulează direct pe gazdă — gazda poate fi un server fizic sau o mașină virtuală) sau la endpoint de sarcină de lucru (pentru protejarea aplicațiilor care rulează în containere sau mașini virtuale găzduite pe gazdă). Politicile Calico permit aplicarea de măsuri de securitate pentru diferite puncte de rutare ale pachetelor prin opțiuni precum preDNAT, unraracked și applyOnForward. Înțelegerea modului în care funcționează aceste opțiuni poate contribui la îmbunătățirea securității și performanței generale a sistemului. Această articol explică esența acestor parametri de politici Calico (preDNAT, unraracked și applyOnForward), aplicate la endpoint-uri de gazdă, punând accent pe ceea ce se întâmplă în rutele de procesare a pachetelor (lanțurile iptables).

Acest articol presupune că aveți o înțelegere de bază a principiilor de funcționare ale politicilor de rețea Kubernetes și Calico. Dacă nu, vă recomandăm să încercați tutorialul de politică de rețea de bază și tutorialul de protecție a gazdelor utilizând Calico înainte de a citi acest articol. De asemenea, ne așteptăm să aveți o înțelegere de bază a funcționării iptables în Linux.

Calico politica globală de rețea vă permite să aplicați un set de reguli de acces pe baza etichetelor (la grupuri de gazde și workloads/pods). Acest lucru este foarte util dacă utilizați împreună sisteme heterogene — mașini virtuale, sisteme direct pe hardware sau infrastructură Kubernetes. În plus, puteți proteja cluster-ul dvs. (nodurile) utilizând un set de politici declarative și aplica politici de rețea la traficul de intrare (de exemplu, prin serviciile NodePorts sau IP-uri externe).

La un nivel fundamental, atunci când Calico conectează un pod la rețea (vezi diagrama de mai jos), îl încalță la gazdă printr-un interfață virtuală Ethernet (veth). Traficul trimis de pod ajunge la gazdă de la această interfață virtuală și este procesat la fel ca și cum ar fi venit de la o interfață de rețea fizică. În mod implicit, Calico numește aceste interfețe caliXXX. Deoarece traficul intră prin interfața virtuală, acesta trece prin iptables, ca și cum pod-ul s-ar afla la o distanță de un hop. Astfel, când traficul ajunge/iese din pod, este redirecționat din punctul de vedere al gazdei.

Pe nodul Kubernetes pe care rulează Calico, poți asocia interfața virtuală (veth) cu workload-ul după cum urmează. În exemplul de mai jos, poți observa că veth#10 (calic1cbf1ca0f8) este conectat la cnx-manager-* în spațiul de nume calico-monitoring.

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

Având în vedere că Calico creează o interfață veth pentru fiecare workload, cum aplică acesta politicile? Pentru asta, Calico creează hook-uri în diverse lanțuri de procesare a pachetelor, folosind iptables.

În diagrama de mai jos sunt prezentate lanțurile implicate în procesarea pachetelor în iptables (sau subsistemul netfilter). Când un pachet ajunge prin interfața de rețea, acesta trece prima dată prin lanțul PREROUTING. Apoi se ia o decizie de rutare și, pe baza acesteia, pachetul trece fie prin INPUT (destinat proceselor gazdei), fie prin FORWARD (destinat pod-ului sau unei alte noduri din rețea). De la procesul local, pachetul trece prin lanțul OUTPUT, iar apoi POSTROUTING înainte de a fi trimis prin cablu.

Reține că pod-ul este de asemenea un obiect extern (conectat prin veth) din perspectiva procesării iptables. Rezumând:

• Traficul redirecționat (forwarded) (nat, rutabil sau în/din pod) trece prin lanțurile PREROUTING – FORWARD – POSTROUTING.
• Traficul către procesul gazdei locale trece prin lanțul PREROUTING – INPUT.
• Traficul din procesul gazdelor locale trece prin lanțul OUTPUT – POSTROUTING.

Calico oferă opțiuni pentru politici, prin care se pot aplica politici pentru toate lanțurile. Având în vedere acest lucru, să analizăm diferitele opțiuni de configurare a politicărilor disponibile în Calico. Numerele din lista de opțiuni de mai jos corespund numerelor din diagramă.

1. Politica endpoint-ului workload (pod)
2. Politica endpoint-ului host
3. Opțiunea ApplyOnForward
4. Politica PreDNAT
5. Politica Untracked

Să începem prin a analiza modul în care se aplică politicile la endpoint-urile workload (pod-urile Kubernetes sau VM-urile OpenStack), iar apoi să examinăm opțiunile de politici pentru endpoint-urile host.

Endpoint-uri Workload

Politica Endpoint-ului Workload (1)

Aceasta este o opțiune pentru protejarea pod-urilor Kubernetes. În Calico, este suportată lucrul cu Kubernetes NetworkPolicy, dar de asemenea oferă politici suplimentare - Calico NetworkPolicy și GlobalNetworkPolicy. Calico creează un lanț pentru fiecare pod (workload) și leagă în lanțurile INPUT și OUTPUT pentru workload la tabela de filtre a lanțului FORWARD.

Endpoint-uri Host

Politica Endpoint-ului Host (2)

Pe lângă CNI (interfața rețelei containerului), politicile Calico oferă posibilitatea de a proteja direct hostul. În Calico, puteți crea un endpoint host specificând o combinație a interfeței host și, dacă este necesar, a numerelor de porturi. Aplicarea politicilor pentru această entitate se realizează prin intermediul tabelei de filtre în lanțurile INPUT și OUTPUT. Așa cum se poate observa din diagramă, (2) acestea se aplică proceselor locale de pe nod/host. Asta înseamnă că, dacă ați creat o politică care se aplică endpoint-ului host, ea nu va afecta traficul care se îndreaptă spre/de la pod-urile dvs. Totuși, aceasta asigură o interfață/sintaxă unică pentru blocarea traficului pe host și pod-uri prin intermediul politicilor Calico. Acest lucru simplifică semnificativ procesul de gestionare a politicilor pentru o rețea diversificată. Configurarea politicilor endpoint-ului host pentru a întări protecția cluster-ului este un alt caz important de utilizare.

Politica ApplyOnForward (3)

Opțiunea ApplyOnForward este disponibilă în politica globală de rețea Calico, pentru a permite aplicarea politicilor la tot traficul care trece prin endpoint-ul host, inclusiv traficul care va fi redirecționat de host (forwarded). Acest trafic include datele trimise către un pod local sau către orice altă destinație din rețea. Calico necesită ca această setare să fie activată pentru politicile care utilizează PreDNAT și untracked, vezi secțiunile următoare. În plus, ApplyOnForward poate fi utilizat pentru a urmări traficul hostului în cazurile în care se utilizează un router virtual sau NAT software.

Observați că dacă trebuie să aplicați aceeași politică de rețea atât pentru procesele gazdă, cât și pentru poduri, nu este necesar să utilizați opțiunea ApplyOnForward. Este suficient să creați un label pentru endpoint-urile gazdă și endpoint-urile de lucru (pod). Calico este suficient de inteligent pentru a aplica politica pe baza label-urilor, indiferent de tipul endpoint-ului (hostendpoint sau workload).

Politica PreDNAT (4)

În Kubernetes, porturile entității service pot fi expuse extern prin opțiunea NodePorts sau, opțional (când se utilizează Calico), prin declararea acestora prin opțiunile Cluster IPs sau External IPs. Kube-proxy echilibrează traficul de intrare asociat service-ului la pod-urile corespunzătoare, folosind DNAT. Având în vedere acest lucru, cum puteți aplica politicile pentru traficul care intră prin NodePorts? Pentru ca aceste politici să fie aplicate înainte ca traficul să fie procesat de DNAT (care reprezintă asortarea gazdă: port și service-ului corespunzător), Calico oferă un parametru pentru globalNetworkPolicy numit „preDNAT: true”.

Când pre-DNAT este activat, aceste politici sunt implementate în (4) pe diagramă — în tabela mangle a lanțului PREROUTING — imediat înainte de DNAT. Ordinea obișnuită a politicilor (order) nu este respectată aici, deoarece aplicarea acestor politici are loc mult mai devreme în calea de procesare a traficului. Cu toate acestea, politicile preDNAT respectă ordinea de aplicare (order) între ele.

Când creați politici cu pre-DNAT, este important să fiți atenți la traficul pe care doriți să-l procesați și să permiteți majorității să fie respinsă. Traficul marcat ca 'allow' în politica pre-DNAT nu va mai fi verificat de politica hostendpoint, în timp ce traficul care nu trece de politica pre-DNAT își va continua drumul prin celelalte lanțuri.
Calico a făcut obligatorie activarea opțiunii applyOnForward atunci când se utilizează preDNAT, deoarece, prin definiție, destinația traficului nu a fost încă selectată. Traficul poate fi direcționat către un proces-gazdă, sau poate fi redirecționat către un pod sau o altă nod.

Politica Untracked (5)

Rețelele și aplicațiile pot avea diferențe semnificative în comportament. În unele cazuri extreme, aplicațiile pot genera numeroase conexiuni de scurtă durată. Acest lucru poate duce la o insuficiență de memorie în conntrack (componenta principală a stivei de rețea Linux). În mod tradițional, pentru a rula aplicații de acest tip în Linux, trebuie să configurați manual sau să dezactivați conntrack, sau să scrieți reguli iptables pentru a ocoli conntrack. Politica untracked în Calico este o opțiune mai simplă și mai eficientă, dacă doriți să gestionați conexiunile cât mai repede posibil. De exemplu, dacă utilizați un array masiv memcache sau ca măsură suplimentară de protecție împotriva DDOS.

Citiți acest blog post (sau în traducerea noastră) pentru informații suplimentare, inclusiv teste de performanță utilizând politica untracked.

Când setați opțiunea „doNotTrack: true” în politica de rețea globală Calico, aceasta devine o politică **neaprobată** și se aplică în cea mai timpurie etapă a procesării pachetelor Linux. Dacă ne uităm la diagrama de mai sus, politicile untracked se aplică în lanțurile PREROUTING și OUTPUT din tabela raw, înainte ca urmărirea conexiunilor (conntrack) să fie inițiată. Când un pachet este permis de politica untracked, acesta este marcat pentru a dezactiva urmărirea conexiunii pentru acel pachet. Aceasta înseamnă că:

• Politica untracked se aplică fiecărui pachet. Nu există noțiunea de conexiune (sau flux). Absența conexiunilor (connection) are câteva consecințe importante:
• Dacă doriți să permiteți atât traficul de cerere, cât și traficul de răspuns, va trebui să aveți o regulă atât pentru intrare, cât și pentru ieșire (deoarece Calico de obicei folosește conntrack pentru a marca traficul de răspuns ca permis).
• Politica untracked nu funcționează pentru workload-uri Kubernetes (pod-uri), deoarece în acest caz nu există nicio modalitate de a urmări conexiunea de ieșire din pod.
• NAT funcționează incorect cu pachete neaprobată (deoarece nucleul păstrează maparea NAT în conntrack).
• Când treceți prin regula „permite totul” din politica untracked, toate pachetele vor fi marcate ca neaprobată. Aceasta nu este aproape niciodată ceea ce doriți, așa că este important să fiți foarte selectivi cu privire la pachetele permise de politicile untracked (și să lăsați cea mai mare parte a traficului să treacă prin politicile normale de urmărire).
• Politicile ne urmărite sunt aplicate la începutul procesului de procesare a pachetelor. Este foarte important să înțelegeți acest lucru atunci când creați politici Calico. Puteți avea o politică pentru pod cu order:1 și o politică ne urmărită cu order:1000. Acest lucru nu va conta. Politica ne urmărită va fi aplicată înaintea politicii pentru pod. Politicile ne urmărite respectă ordinea de execuție doar între ele.

Deoarece unul dintre obiectivele politicii doNotTrack este aplicarea forțată a politicii într-un stadiu inițial al procesului de procesare a pachetelor Linux, Calico impune specificarea opțiunii applyOnForward atunci când se utilizează doNotTrack. Consultând diagrama de procesare a pachetelor, rețineți că politica ne urmărită (5) este aplicată înainte de orice decizie de rutare. Traficul poate fi direcționat către procesul gazdă sau poate fi redirecționat către un pod sau către un alt nod.

Concluzii

Am analizat diferitele opțiuni de politici (Host endpoint, ApplyOnForward, preDNAT și Untracked) în Calico și cum sunt aplicate pe parcursul procesului de procesare a pachetelor. Înțelegerea esenței modului în care acestea funcționează ajută la dezvoltarea unor politici eficiente și sigure. Cu ajutorul Calico, puteți utiliza politica globală de rețea, care se aplică etichetei (grupului de noduri și poduri) și aplica politici cu diferite parametri. Acest lucru le permite specialiștilor în securitate și proiectare de rețea să protejeze în mod convenabil totul (tipuri de endpoints), folosind un singur limbaj de politici cu politicile Calico.

Mulțumiri: Aș dori să mulțumesc Shawn Crampton și Alex Pollitt pentru recenzia lor și pentru informațiile valoroase.

Sursa: habr.com