Pluginul de rețea Calico oferă o gamă largă de politici de rețea cu o sintaxă unificată pentru a proteja gazdele hardware, mașinile virtuale și podurile. Aceste politici pot fi aplicate într-un spațiu de nume sau pot fi politici globale de rețea care se aplică (pentru a proteja aplicațiile care rulează direct pe gazdă - gazda poate fi un server sau o mașină virtuală) sau (pentru a proteja aplicațiile care rulează în containere sau mașini virtuale găzduite). Politicile Calico vă permit să aplicați măsuri de securitate în diferite puncte din calea unui pachet folosind opțiuni precum preDNAT, unraracked și applyOnForward. Înțelegerea modului în care funcționează aceste opțiuni poate ajuta la îmbunătățirea securității și a performanței întregului sistem. Acest articol explică esența acestor opțiuni de politică Calico (preDNAT, unraracked și applyOnForward) aplicate punctelor finale gazdă, cu accent pe ceea ce se întâmplă în căile de procesare a pachetelor (lanțuri iptabels).
Acest articol presupune că aveți o înțelegere de bază a modului în care funcționează politicile de rețea Kubernetes și Calico. Dacă nu, vă recomandăm să încercați и folosind Calico înainte de a citi acest articol. De asemenea, ne așteptăm să aveți o înțelegere de bază a lucrării în linux.
Stambă vă permite să aplicați un set de reguli de acces după etichete (la grupuri de gazde și încărcături de lucru/pod-uri). Acest lucru este foarte util dacă utilizați împreună sisteme eterogene - mașini virtuale, un sistem direct pe hardware sau o infrastructură kubernetes. În plus, vă puteți proteja clusterul (nodurile) folosind un set de politici declarative și puteți aplica politici de rețea traficului de intrare (de exemplu, prin serviciul 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 conectează la gazdă folosind o interfață Ethernet virtuală (veth). Traficul trimis de pod vine la gazdă de la această interfață virtuală și este procesat în același mod ca și cum ar proveni dintr-o interfață fizică de rețea. În mod implicit, Calico numește aceste interfețe caliXXX. Deoarece traficul vine prin interfața virtuală, trece prin iptables ca și cum pod-ul ar fi la un hop distanță. Prin urmare, atunci când traficul vine către/de la un pod, acesta este redirecționat din punctul de vedere al gazdei.
Pe un nod Kubernetes care rulează Calico, puteți mapa o interfață virtuală (veth) la o sarcină de lucru, după cum urmează. În exemplul de mai jos, puteți vedea 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: <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
...
Având în vedere că Calico creează o interfață veth pentru fiecare sarcină de lucru, cum aplică politicile? Pentru a face acest lucru, Calico creează cârlige în diferite lanțuri ale căii de procesare a pachetelor folosind iptables.
Diagrama de mai jos arată lanțurile implicate în procesarea pachetelor în iptables (sau subsistemul netfilter). Când un pachet ajunge printr-o interfață de rețea, mai întâi trece prin lanțul PREROUTING. Se ia apoi o decizie de rutare și pe baza acesteia, pachetul trece fie prin INPUT (direcționat către procesele gazdă), fie FORWARD (direcționat către un pod sau alt nod din rețea). Din procesul local, pachetul trece prin lanțul OUTPUT și apoi POSTROUTING înainte de a fi trimis pe cablu.
Rețineți că pod-ul este, de asemenea, o entitate externă (conectată la veth) în ceea ce privește procesarea iptables. Să rezumăm:
- Traficul redirecționat (nat, direcționat sau către/de la un pod) trece prin lanțurile PREROUTING - FORWARD - POSTROUTING.
- Traficul către procesul gazdă local trece prin lanțul PREROUTING - INPUT.
- Traficul din procesul gazdă local trece prin lanțul OUTPUT - POSTROUTING.
Calico oferă opțiuni de politică care vă permit să aplicați politici în toate lanțurile. Având în vedere acest lucru, să ne uităm la diferitele opțiuni de configurare a politicilor disponibile în Calico. Numerele din lista de opțiuni de mai jos corespund numerelor din diagrama de mai sus.
- Politica privind punctul final al sarcinii de lucru (pod).
- Politica punctului final gazdă
- Opțiunea ApplyOnForward
- Politica PreDNAT
- Politică fără urmărire
Să începem prin a ne uităm la modul în care politicile sunt aplicate punctelor finale ale încărcăturii de lucru (pod-uri Kubernetes sau mașini virtuale OpenStack), apoi ne uităm la opțiunile de politică pentru punctele finale gazdă.
Puncte finale ale sarcinii de lucru
Politica privind nivelul final al sarcinii de lucru (1)
Aceasta este o opțiune pentru a vă proteja podurile kubernetes. Calico acceptă lucrul cu Kubernetes NetworkPolicy, dar oferă și politici suplimentare - Calico NetworkPolicy și GlobalNetworkPolicy. Calico creează un lanț pentru fiecare pod (sarcină de lucru) și se conectează în lanțurile INPUT și OUTPUT pentru volumul de lucru la tabelul de filtrare al lanțului FORWARD.
Puncte finale gazdă
Politica privind punctele finale gazdă (2)
Pe lângă CNI (interfață de rețea container), politicile Calico oferă capacitatea de a proteja gazda în sine. În Calico, puteți crea un punct final gazdă specificând o combinație de interfață gazdă și, dacă este necesar, numere de port. Aplicarea politicii pentru această entitate se realizează folosind un tabel de filtrare în lanțurile INPUT și OUTPUT. După cum puteți vedea din diagramă, (2) se aplică proceselor locale de pe nod/gazdă. Adică, dacă creați o politică care se aplică punctului final gazdă, aceasta nu va afecta traficul care merge către/de la podurile dvs. Dar oferă o singură interfață/sintaxă pentru blocarea traficului pentru gazdă și pod-uri folosind politicile Calico. Acest lucru simplifică foarte mult procesul de gestionare a politicilor pentru o rețea eterogenă. Configurarea politicilor de terminale gazdă pentru a îmbunătăți securitatea clusterului este un alt caz de utilizare important.
Politica ApplyOnForward (3)
Opțiunea ApplyOnForward este disponibilă în politica de rețea globală Calico pentru a permite politicilor să fie aplicate întregului trafic care trece prin punctul final de gazdă, inclusiv traficul care va fi redirecționat de gazdă. Aceasta include traficul redirecționat către podul local sau oriunde altundeva din rețea. Calico necesită ca această setare să fie activată pentru politicile care utilizează PreDNAT și nu sunt urmărite, consultați secțiunile următoare. În plus, ApplyOnForward poate fi folosit pentru a monitoriza traficul gazdei în cazurile în care este utilizat un router virtual sau software NAT.
Rețineți că, dacă trebuie să aplicați aceeași politică de rețea atât proceselor gazdă, cât și podurilor, atunci nu trebuie să utilizați opțiunea ApplyOnForward. Tot ce trebuie să faceți este să creați o etichetă pentru punctul final de gazdă și punctul final al sarcinii de lucru (pod). Calico este suficient de inteligent pentru a pune în aplicare politica bazată pe etichete, indiferent de tipul punctului final (punct gazdă sau sarcină de lucru).
Politica PreDNAT (4)
În Kubernetes, porturile entităților de serviciu pot fi expuse extern folosind opțiunea NodePorts sau, opțional (când se folosește Calico), prin promovarea lor folosind opțiunile IP-uri Cluster sau IP-uri externe. Kube-proxy echilibrează traficul de intrare legat de un serviciu către podurile serviciului corespunzător folosind DNAT. Având în vedere acest lucru, cum aplicați politicile pentru traficul care vine prin NodePorts? Pentru a se asigura că aceste politici sunt aplicate înainte ca traficul să fie procesat de DNAT (care este o mapare între gazdă:port și serviciul corespunzător), Calico oferă un parametru pentru globalNetworkPolicy numit „preDNAT: true”.
Atunci când pre-DNAT este activat, aceste politici sunt implementate în (4) în diagramă - în tabelul Mangle al lanțului PREROUTING - imediat înainte de DNAT. Ordinea obișnuită a politicilor nu este urmată aici, deoarece aplicarea acestor politici are loc mult mai devreme în calea de procesare a traficului. Cu toate acestea, politicile preDNAT respectă ordinea aplicării î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 respingerea majorității. Traficul marcat ca „permis” în politica pre-DNAT nu va mai fi verificat de politica hostendpoint, în timp ce traficul care nu respectă politica pre-DNAT va continua prin lanțurile rămase.
Calico a făcut obligatorie activarea opțiunii applyOnForward atunci când utilizați preDNAT, deoarece, prin definiție, destinația traficului nu a fost încă selectată. Traficul poate fi direcționat către procesul gazdă sau poate fi redirecționat către un pod sau un alt nod.
Politică fără urmărire (5)
Rețelele și aplicațiile pot avea diferențe mari de comportament. În unele cazuri extreme, aplicațiile pot genera multe conexiuni de scurtă durată. Acest lucru poate face ca conntrack (o componentă de bază a stivei de rețea Linux) să rămână fără memorie. În mod tradițional, pentru a rula aceste tipuri de aplicații pe Linux, ar trebui să configurați sau să dezactivați manual conntrack, sau să scrieți reguli iptables pentru a ocoli conntrack. Politica fără urmărire în Calico este o opțiune mai simplă și mai eficientă dacă doriți să procesați conexiunile cât mai repede posibil. De exemplu, dacă utilizați masiv sau ca măsură suplimentară de protecţie împotriva .
Citeste acest (Sau, ) pentru mai multe informații, inclusiv teste de performanță folosind politica neurmărită.
Când setați opțiunea „doNotTrack: true” în Calico globalNetworkPolicy, aceasta devine o politică **neurmărită** și este aplicată foarte devreme în pipeline de procesare a pachetelor Linux. Privind diagrama de mai sus, politicile neurmărite sunt aplicate în lanțurile PREROUTING și OUTPUT din tabelul brut înainte de a începe urmărirea conexiunii (conntrack). Când un pachet este permis de politica neurmărită, este marcat pentru a dezactiva urmărirea conexiunii pentru acel pachet. Inseamna:
- Politica neurmărită se aplică pe bază de pachet. Nu există conceptul de conexiune (sau flux). Lipsa conexiunilor are câteva consecințe importante:
- Dacă doriți să permiteți atât traficul de cerere, cât și cel de răspuns, aveți nevoie de o regulă atât pentru intrare, cât și pentru ieșire (deoarece Calico utilizează de obicei conntrack pentru a marca traficul de răspuns ca permis).
- Politica neurmărită nu funcționează pentru sarcinile de lucru Kubernetes (pod-uri), deoarece în acest caz nu există nicio modalitate de a urmări conexiunea de ieșire din pod.
- NAT nu funcționează corect cu pachetele neurmărite (deoarece nucleul stochează maparea NAT în conntrack).
- Când treceți prin regula „permiteți toate” din politica neurmărită, toate pachetele vor fi marcate ca neurmărite. Acest lucru nu este aproape întotdeauna ceea ce doriți, așa că este important să fiți foarte selectiv în ceea ce privește pachetele permise de politicile neurmărite (și să permiteți ca majoritatea traficului să treacă prin politicile normale de urmărire).
- Politicile neurmărite sunt aplicate chiar de la începutul conductei de procesare a pachetelor. Acest lucru este foarte important de înțeles când creați politici Calico. Puteți avea o politică de pod cu order:1 și o politică neurmărită cu order:1000. Nu va conta. Politica Untracked va fi aplicată înaintea politicii pentru pod. Politicile neurmărite respectă ordinea de execuție numai între ele.
Deoarece unul dintre scopurile politicii doNotTrack este de a aplica politica foarte devreme în pipeline de procesare a pachetelor Linux, Calico face obligatorie specificarea opțiunii applyOnForward atunci când utilizați doNotTrack. Referindu-ne la diagrama de procesare a pachetelor, rețineți că politica untracked(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 un alt nod.
Rezultatele
Am analizat diferitele opțiuni de politică (punct final gazdă, ApplyOnForward, preDNAT și Untracked) în Calico și modul în care sunt aplicate de-a lungul căii de procesare a pachetelor. Înțelegerea modului în care funcționează ajută la dezvoltarea unor politici eficiente și sigure. Cu Calico puteți utiliza o politică globală de rețea care se aplică unei etichete (un grup de noduri și poduri) și puteți aplica politici cu diverși parametri. Acest lucru permite profesioniștilor în domeniul securității și al designului de rețele să protejeze convenabil „totul” (tipuri de puncte finale) simultan, folosind un singur limbaj de politică cu politicile Calico.
Recunoaștere: Aș dori să mulțumesc и pentru revizuirea și informațiile lor prețioase.
Sursa: www.habr.com