Calico şəbəkə plaqini, fiziki hostlar, virtual maşınlar və pod'lar üçün qoruma təmin edən birləşdirilmiş sintaksis ilə geniş bir şəbəkə siyasəti dəstini təqdim edir. Bu siyasətlər, namespace çərçivəsində tətbiq oluna bilər və ya (hostda birbaşa işləyən tətbiqləri qorumaq üçün — host birbaşa server və ya virtual maşın ola bilər) və ya (hostda yerləşdirilən konteynerlər və ya virtual maşınlarda işləyən tətbiqləri qorumaq üçün). Calico siyasətləri, preDNAT, unraracked və applyOnForward kimi parametrlərdən istifadə edərək paketlərin müxtəlif yük yolları üçün təhlükəsizlik tədbirləri tətbiq etməyə imkan verir. Bu variantların necə işlədiyini anlamaq, sistemin ümumi təhlükəsizliyi və performansını artırmağa kömək edə bilər. Bu məqalədə, host endpoint-lərə tətbiq olunan Calico siyasət parametrlərinin (preDNAT, unraracked və applyOnForward) mahiyyəti izah edilir, paketlərin emal olma yollarında (iptables zəncirləri) baş verənlərə diqqət yetirilir.
Bu məqalə, sizdə Kubernetes və Calico şəbəkə siyasətləri ilə bağlı əsas anlayışların olduğunu nəzərdə tutur. Əgər yoxdursa, o zaman və ilə Calico-dan istifadə etməyi tövsiyə edirik, bu məqaləni oxumadan əvvəl. Həmçinin, sizin Linux-un iş prinsiplərinə dair əsas anlayışa malik olduğunuzu gözləyirik. in Linux.
Calico etiketlər (hostlar və workloads/pods qrupları) əsasında giriş qaydaları tətbiq etməyə imkan verir. Bu, müxtəlif sistemləri — virtual maşınlar, fiziki host sistemi və ya kubernetes infrastrukturu kimi birlikdə istifadə edərkən çox faydalıdır. Həm də, klasterinizi (nodelər) deklarativ siyasətlər dəstəyi ilə qoruya və şəbəkə siyasətlərini daxil olan trafikə tətbiq edə bilərsiniz (məsələn, NodePorts və ya Xarici IP-lər vasitəsilə).
Əsas səviyyədə, Calico pod'u şəbəkəyə qoşduqda (aşağıdakı diaqramı nəzərə alın), onu virtual Ethernet interfeysi (veth) vasitəsilə hosta qoşur. Pod tərəfindən göndərilən trafik, bu virtual interfeysdən hosta gəlir və fiziki şəbəkə interfeysindən gəlmiş kimi işlənir. Varsayılan olaraq Calico bu interfeysləri caliXXX adlandırır. Trafik virtual interfeys vasitəsilə gəldiyi üçün, bu, pod'un bir hop məsafəsində olması kimi iptables-dan keçir. Beləliklə, trafik pod'dan gələn/getməklə, hostdan baxışdan ötürülür (forwarded).
Calico-nun işə salındığı Kubernetes nodunda, virtual interfeysi (veth) workload ilə aşağıdakı kimi uyğunlaşdıra bilərsiniz. Aşağıdakı nümunədə, veth#10 (calic1cbf1ca0f8) calico-monitoring namespace-də cnx-manager- * ilə qoşulduğunu görə bilərsiniz.
[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
... 
Calico hər workload üçün veth interfeysi yaradaraq siyasətləri necə tətbiq edir? Bunun üçün Calico paketlərin emal zəncirlərində iptables istifadə edərək, müxtəlif ipləri əlavə edir.
Aşağıdakı diaqramda iptables (və ya netfilter sistemində) paketlərin emalında iştirak edən zəncirlər göstərilmişdir. Paket şəbəkə interfeysindən daxil olduqda, əvvəlcə PREROUTING zəncirindən keçir. Daha sonra marşrutlaşdırma qərarı alınır və buna əsasən paket ya INPUT (ev sahibinin proseslərinə yönəldilmiş) ya da FORWARD (pod ya da şəbəkədə digər düyünə yönəldilmiş) vasitəsilə keçirilir. Yerli prosesdən paket OUTPUT zəncirindən keçir, sonra POSTROUTING zəncirinə keçirilərək kabel üzərindən göndərilir.
Qeyd edək ki, pod da iptables emalından baxıldığında xarici bir obyekt (veth ilə bağlı)dir. Xülasə edək:
- İlə yönəldilmiş (forwarded) trafik (nat, marşrutlaşdırılan və ya pod içində/out of pod) PREROUTING — FORWARD — POSTROUTING zəncirlərindən keçir.
- Trafik yerli ev sahibi prosesinə PREROUTING — INPUT zəncirindən keçir.
- Lokal ev sahibi prosesindən gələn trafik OUTPUT — POSTROUTING zəncirindən keçir.
Calico, bütün zəncirlərə siyasət tətbiq etməyə imkan verən variantlar təqdim edir. Bununla yanaşı, gəlin Calico-da mövcud olan müxtəlif siyasət konfiqurasiyalarına baxaq. Aşağıdakı siyahıdakı rəqəmlər yuxarıdakı diaqramdakı rəqəmlərə uyğundur.
- Workload endpoint (pod) siyasəti
- Host endpoint siyasəti
- ApplyOnForward seçimi
- PreDNAT siyasəti
- Untracked siyasəti
Gəlin əvvəlcə workload endpoints (Kubernetes pod-ları və ya OpenStack VMs) üçün siyasətlərin necə tətbiq edildiyinə baxaq, sonra host endpoints üçün siyasət variantlarını müzakirə edək.
Workload Endpoints
Workload Endpoint Siyasəti (1)
Bu, kubernetes pod-larınızı qorumaq üçün bir seçimdir. Calico Kubernetes NetworkPolicy ilə işləməyi dəstəkləyir, lakin əlavə siyasətlər təqdim edir - Calico NetworkPolicy və GlobalNetworkPolicy. Calico, hər pod (workload) üçün bir zəncir yaradır və INPUT və OUTPUT zəncirlərinə workload üçün FORWARD filter zəncirini əlavə edir.
Host Endpoints
Host Endpoint Siyasəti (2)
CNI (container network interface) ilə yanaşı, Calico siyasətləri ev sahibi təsisatı birbaşa qorumaq imkanı verir. Calico-da, siz host endpoint yaratmaqla ev sahibi interfeysi və ehtiyac olarsa, port nömrələrinin birləşməsini təyin edə bilərsiniz. Bu varlığın siyasətinin tətbiqi INPUT və OUTPUT zəncirində filtr cədvəli vasitəsilə həyata keçirilir. Diaqramdan görünür ki, onlar (2) nodda/ev sahibi üzərindəki lokal proseslərə tətbiq olunur. Yəni, əgər ev sahibi endpoint-ə tətbiq olunan bir siyasət yaratmışsınızsa, bu, sizin pod'larınıza gələn və gedən trafikə təsir etməyəcək. Lakin bu, ev sahibiniz və pod'larınız üçün trafikə bloklamaq üçün birinci mühit/sintaksis təmin edir, yəni Calico siyasətləri ilə. Bu, müxtəlif şəbəkələr üçün siyasətlərin idarə edilməsini əhəmiyyətli dərəcədə asanlaşdırır. Klasteri qorumaq üçün host endpoint siyasətlərinin təyini — onların istifadəsi üçün daha bir vacib hallardan biridir.
ApplyOnForward Siyasəti (3)
ApplyOnForward seçimi Calico global şəbəkə siyasətində host endpoint vasitəsilə ötürülən bütün trafikə siyasətlərin tətbiqi üçün imkan təmin etmək məqsədini güdür, daxil olmaqla, host tərəfindən yönləndiriləcək trafik (forwarded). Bu trafik lokal pod-a və ya şəbəkənin başqa bir yerinə göndəriləni əhatə edir. Calico, PreDNAT və untracked istifadə edən siyasətlər üçün bu parametrin aktiv olmasını tələb edir, baxın sonrakı bölmələr. Həmçinin, ApplyOnForward host trafikinin izini sürmək üçün virtual router və ya proqram təminatlı NAT istifadə edildikdə istifadə oluna bilər.
Qeyd edin ki, əgər siz eyni şəbəkə siyasətini həm ev sahibi proseslərə, həm də pod'lara tətbiq etmək istəyirsinizsə, ApplyOnForward seçimini istifadə etməyə ehtiyac yoxdur. Ehtiyac duyduğunuz host endpoint və workload endpoint (pod) üçün bir label yaratmağınız yetərlidir. Calico, siyasəti labels əsasında tətbiq etməkdə kifayət qədər ağıllıdır, endpoint (host endpoint və ya workload) tipindən asılı olmayaraq.
PreDNAT Siyasəti (4)
Kubernetes-də service varlığının portları NodePorts seçimi ilə xaricə buraxıla bilər və ya (Calico istifadə edildiyi halda) onları Cluster IPs və ya External IPs seçimləri ilə bəyan etməklə əlavə olaraq. Kube-proxy, DNAT istifadə edərək, service-ə bağlı incoming trafikini müvafiq pod'lara yönləndirir. Bunu nəzərə alaraq, NodePorts vasitəsilə gələn trafik üçün siyasətləri necə tətbiq edirsiniz? Bu siyasətlərin DNAT tərəfindən processed-before-dnat (host: port və müvafiq service-nin uyğunluğunu təmsil edən) tətbiq edilmədən əvvəl tətbiq olunması üçün Calico, globalNetworkPolicy üçün "preDNAT: true" adında bir parametr təklif edir.
pre-DNAT aktiv olduqda, bu siyasətlər (4) diaqramda — DNAT-dan əvvəl PREROUTING zəncirində tənzimlənir. Normal siyasət sırası burada təmin olunmur, çünki bu siyasətlərin tətbiqi trafik emalı müddətində çox daha əvvəl baş verir. Bununla belə, preDNAT siyasətləri bir-birinin üzərində tətbiq sırasını (order) qoruyur.
Pre-DNAT siyasətlərini yaratarkən işlədilməli olan trafikə diqqət yetirmək və əksəriyyətin imtina edilməsinə icazə vermək vacibdir. Pre-DNAT siyasətində 'icazə ver' kimi qeyd olunan trafik artıq hostendpoint siyasəti ilə yoxlanmayacaq, o zaman pre-DNAT siyasətindən keçməyən trafik digər zəncirlərlə davam edəcək.
Calico, preDNAT istifadə edərkən applyOnForward seçiminin daxil edilməsini zəruri etdi, çünki trafikin mənbəyi hələ seçilməyib. Trafik host prosesi, pod və ya digər bir node-a yönləndirilə bilər.
İzlənməyən Siyasət (5)
Şəbəkələr və tətbiqlər davranışlarında böyük fərqlər göstərə bilər. Bəzi ekstremal hallarda tətbiqlər çoxsaylı qısa müddətli bağlantılar yarada bilər. Bu, Linux şəbəkə yığınının əsas komponenti olan conntrack-da yaddaş çatışmazlığına səbəb ola bilər. Belə tipli tətbiqlərin işlədilməsi üçün Linux-da conntrack-i əl ilə tənzimləmək və ya söndürmək ya da conntrack-i keçən iptables qaydaları yazmaq lazımdır. Calico-da izlənməyən siyasət, bağlantıları ən sürətli şəkildə işləməyi istəyirsinizsə, daha sadə və təsirli bir seçimdir. Məsələn, əgər siz massiv bir və ya .
bu məlumatı oxuyun (və ya ) izlənməyən siyasət istifadə edərkən performans testləri də daxil olmaqla daha çox məlumat üçün.
Calico globalNetworkPolicy-də "doNotTrack: true" seçimini qeyd etdiyiniz zaman bu siyasət **izlənməyən** və Linux paket emalı konveyerinin ən erkən mərhələsində tətbiq olunur. Yuxarıdakı diaqramda baxdığınızda, izlənməyən siyasətlər raw cədvəldə PREROUTING və OUTPUT zəncirlərində tətbiq olunur, conntrack işə salınmadan əvvəl. Bir paket izlənməyən siyasət tərəfindən icazə verildikdə, o, bu paketin bağlantısını izləməsini deaktiv etmək üçün işarələnir. Bu, deməkdir ki:
- İzlənməyən siyasət hər paket üçün tətbiq olunur. Bağlantı (və ya axın) anlayışı yoxdur. Bağlantıların olmaması bir neçə mühüm nəticəni ortaya çıxarır:
- Siz həm sorğu trafikinə, həm də cavab trafikinə icazə vermək istəyirsinizsə, həm daxil olan, həm də çıxan üçün bir qayda lazım olacaq (çünki Calico adətən cavab trafiki icazə verilmiş kimi işarələmək üçün conntrack-i istifadə edir).
- İzlənməyən siyasət Kubernetes iş yükü (pod-lar) üçün işləməyir, çünki bu halda pod-dan çıxan bağlantını izləmək üçün bir yol yoxdur.
- NAT, izlənməyən paketlərlə düzgün işləməyərək (çünki kernel NAT uyğunluğunu conntrack-da saxlayır).
- «İcazə ver» qaydası ilə untracked siyasətindən keçdiyiniz zaman, bütün paketlər izlənilməyən kimi işarələnəcək. Bu, demək olar ki, həmişə lazım olmayan bir şeydir, buna görə untracked siyasətlərinə icazə verilən paketlərdə çox seçici olmaq vacibdir (və əksər trafiğin normal izlənilən siyasətlərlə keçməsinə icazə verin).
- Untracked siyasətləri paketin emalı konveyerinin ən əvvəlki mərhələsində tətbiq olunur. Calico siyasətləri yaradarkən bunun önəmli olduğunu başa düşmək çox vacibdir. Sizde order:1 olan bir pod siyasəti və order:1000 olan bir untracked siyasəti ola bilər. Bu, əhəmiyyətli olmayacaq. Untracked siyasəti pod siyasətindən əvvəl tətbiq olunacaq. Untracked siyasətləri yalnız öz aralarında icra ardıcıllığına riayət edir.
doNotTrack siyasətinin məqsədindən biri Linux paket emalı konveyerinin ən erkən mərhələsində siyasətin icrasını fəal şəkildə təmin etmək olduğundan, Calico doNotTrack istifadə edildikdə applyOnForward seçiminin mütləq göstərilməsini tələb edir. Paket emalı diaqramına müraciət edərək, untracked siyasətinin (5) marşrutlaşdırma qərarlarından əvvəl tətbiq edildiyini qeyd edin. Trafik ev-prosesi yönləndirilə bilər, ya da pod'a və ya başqa bir düyünə yönləndirilə bilər.
Yekunlar
Calico-da siyasətlərin (Host endpoint, ApplyOnForward, preDNAT və Untracked) müxtəlif variantlarını və onların paket emalı yolunda necə tətbiq olunduğunu nəzərdən keçirdik. Onların iş prinsipini başa düşmək, effektiv və təhlükəsiz siyasətlərin inkişafına kömək edir. Calico ilə label (düyünlər və podlar qrupu) üçün tətbiq olunan qlobal şəbəkə siyasətini istifadə edə bilərsiniz və müxtəlif parametrlərə malik siyasətləri tətbiq edə bilərsiniz. Bu, təhlükəsizlik və şəbəkə dizaynı mütəxəssislərinə eyni siyasət dili ilə bütün „şeyləri“ (endpoint tipləri) asanlıqla qoruma imkanı tanıyır.
Təşəkkür: Mən və onların icmalı və dəyərli məlumatları üçün təşəkkür etmək istəyirəm.
Mənbə: habr.com
