A Calico hálózati bővítmény széleskörű hálózati politikákat kínál egységes szintaxissal a fizikai gépek, virtuális gépek és podok védelmére. Ezek a politikák alkalmazhatóak névtereken belül, vagy lehetnek globális hálózati politikák, amelyek a osztályba tartozó alkalmazások védelmét szolgálják, amelyek közvetlenül a gazdagépen futnak — a gazdagép lehet közvetlenül egy szerver vagy virtuális gép) vagy a (azoknak az alkalmazásoknak a védelme, amelyek konténerekben vagy virtuális gépekben futnak, amelyeket a gazdagépen helyeztek el). A Calico politikák lehetővé teszik a biztonsági intézkedések alkalmazását a csomagok különböző útvonalain a preDNAT, unraracked és applyOnForward paraméterek segítségével. Ezeknek az opcióknak a megértése segíthet növelni a rendszer biztonságát és teljesítményét összességében. Ez a cikk magyarázza a Calico politikák (preDNAT, unraracked és applyOnForward) lényegét, amelyek a host endpoints-hoz kapcsolódnak, kiemelve, hogy mi történik a csomagok feldolgozásának útvonalain (iptables láncok).
Ez a cikk azt feltételezi, hogy van egy alapvető megértése a Kubernetes és Calico hálózati politikák működéséről. Ha nincs, akkor javasoljuk, hogy próbálkozzon a és elolvasásával Calico használatával, mielőtt tovább olvasna. Arra is számítunk, hogy van egy alapvető megértése a Linux működéséről.
Calico lehetővé teszi, hogy szabályok halmazát alkalmazza címkék alapján (gazdagépekre és workloads/podokra). Ez nagyon hasznos, ha vegyes rendszereket használ — virtuális gépeket, közvetlenül a hardveren futó rendszereket vagy Kubernetes infrastruktúrát. Ezenkívül védheti klaszterét (csomópontokat) deklaratív politikák halmazával, és alkalmazhat hálózati politikákat a bejövő forgalomra (például NodePortokon vagy külső IP-ken keresztül).
Alapvető szinten, amikor a Calico egy podot csatlakoztat a hálózathoz (lásd az alábbi ábrát), egy virtuális Ethernet interfészen (veth) keresztül kapcsolja össze azt a gazdagéppel. A pod által küldött forgalom ezen a virtuális interfészen keresztül érkezik a gazdagépre, és úgy kezeli, mintha az egy fizikai hálózati interfészen érkezett volna. Alapértelmezés szerint a Calico ezeket az interfészeket caliXXX néven nevezi el. Mivel a forgalom a virtuális interfészen keresztül érkezik, átmegy az iptables-en, mintha a pod egy hop távolságra lenne. Így amikor a forgalom a pod-tól érkezik/kimegy, a gazdagép szempontjából továbbítódik.
A Kubernetes csomóponton, ahol a Calico fut, a virtuális interfészt (veth) a munkaterheléssel az alábbi módon lehet összekapcsolni. Az alábbi példában látható, hogy a veth#10 (calic1cbf1ca0f8) csatlakozik a cnx-manager-*-hez a calico-monitoring névtérben.
[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
... 
Figyelembe véve, hogy a Calico veth interfészt hoz létre minden egyes munkaterheléshez, hogyan alkalmazza a politikákat? Ehhez a Calico horgokat hoz létre a csomagok feldolgozási láncának különböző láncaiba, az iptables használatával.
Az alábbi ábrán láthatók az iptables-ben (vagy netfilter alrendszerben) részt vevő láncok. Amikor egy csomag a hálózati interfészen keresztül érkezik, először a PREROUTING láncon halad át. Ezt követően döntés születik az útválasztásról, és ennek alapján a csomag vagy az INPUT-on (a gazdagép folyamatainak irányába), vagy a FORWARD-on (a pod vagy egy másik csomópont felé a hálózaton) halad át. A lokális folyamatból a csomag az OUTPUT láncon keresztül megy, majd POSTROUTING-on, mielőtt a kábelhez kerül.
Vegye figyelembe, hogy a pod is egy külső objektum (amely a veth-hez kapcsolódik) az iptables feldolgozása szempontjából. Összefoglalva:
- A továbbított forgalom (nat, irányított vagy a podból/kifelé) a PREROUTING — FORWARD — POSTROUTING láncokon halad át.
- A helyi gazdagép-folyamata felé irányuló forgalom a PREROUTING — INPUT láncon keresztül halad.
- A helyi gazdagép-folyamatból kiinduló forgalom az OUTPUT — POSTROUTING láncon halad át.
A Calico lehetőségeket biztosít olyan politikákhoz, amelyekkel politikákat alkalmazhatunk az összes láncra. Ezt figyelembe véve nézzük meg a Calicóban elérhető politikabeállítások különböző lehetőségeit. Az alábbi lehetőségek számai megfelelnek a fenti diagram számainak.
- Workload végponthoz (pod) tartozó politika
- Host végponthoz tartozó politika
- ApplyOnForward lehetőség
- PreDNAT politika
- Untracked politika
Kezdjük azzal, hogy megvizsgáljuk, hogyan alkalmazzuk a politikákat a workload végpontokra (Kubernetes podjaira vagy OpenStack VMs-re), majd nézzük meg a host végpontok politikáit.
Workload végpontok
Workload végpont politika (1)
Ez a lehetőség a Kubernetes podok védelmére szolgál. A Calico támogatja a Kubernetes NetworkPolicy használatát, de további politikákat is biztosít — Calico NetworkPolicy és GlobalNetworkPolicy formájában. A Calico létrehoz egy láncot minden podhoz (workload), és horgokat helyez el az INPUT és OUTPUT láncokban a FORWARD lánc szűrő táblához.
Host végpontok
Host végpont politika (2)
A CNI (container network interface) mellett a Calico politikák lehetőséget biztosítanak a host közvetlen védelmére is. A Calico-ban létrehozhat egy host végpontot a host interfészének és, ha szükséges, portszámok kombinációjának megadásával. E politikák alkalmazása a szűrőtáblák segítségével történik az INPUT és OUTPUT láncokban. Ahogy a diagramon látható, (2) ezek a helyi folyamatokra vonatkoznak a noden/hoston. Tehát ha létrehozott egy politikát, amely a host végpontra vonatkozik, az nem befolyásolja a pod-jaitól érkező vagy oda tartó forgalmat. De ezzel egy egységes interfész/szintaxis biztosítható a host és podok forgalmának blokkolására Calico politikák segítségével. Ez jelentősen egyszerűsíti a politikák kezelését egy heterogén hálózatban. A host végpont politikák beállítása a klaszter védelmének fokozására egy újabb fontos használati eset.
ApplyOnForward politika (3)
Az ApplyOnForward lehetőség elérhető a Calico globális hálózati politikájában, hogy lehetővé tegye politikák alkalmazását az összes forgalomra, amely a host végponton átmegy, beleértve a forgalmat, amelyet a host továbbít (forwarded). Ez a forgalom tartalmazza a helyi podra vagy bárhova máshová a hálózatban továbbított adatokat is. A Calico megköveteli, hogy ezt a paramétert bekapcsolva használják a PreDNAT és untracked politikákban, lásd a következő szakaszokat. Ezen túlmenően az ApplyOnForward használható a host forgalom nyomon követésére virtuális router vagy szoftveres NAT esetén.
Vegye figyelembe, hogy ha ugyanazt a hálózati politikát szeretné alkalmazni a hoszt folyamatokra és a podokra, akkor nem szükséges használni az ApplyOnForward opciót. Elég létrehoznia egy címkét a szükséges hostendpoint és workload endpoint (pod) számára. A Calico eléggé intelligens ahhoz, hogy a címkék alapján alkalmazza a politikát, függetlenül az endpoint típusától (hostendpoint vagy workload).
PreDNAT Politika (4)
A Kubernetesben a service entitás portjai kivehetők a NodePorts opció segítségével, vagy opcionálisan (a Calico használatakor) a Cluster IPs vagy External IPs opciók deklarálásával. A kube-proxy az érkező forgalmat a service-hez tartozó podokhoz irányítja DNAT segítségével. Figyelembe véve ezt, hogyan alkalmazhatják a politikákat a NodePorts-on keresztül érkező forgalomra? Ahhoz, hogy ezek a politikák érvényesek legyenek, mielőtt a forgalom DNAT-on keresztül feldolgozásra kerülne (ami a hoszt:port és a megfelelő service leképezését jelenti), a Calico biztosít egy paramétert a globalNetworkPolicy számára, amelyet „preDNAT: true”-nak neveznek.
Amikor a pre-DNAT engedélyezve van, ezek a politikák a diagram (4)-ben a PREROUTING lánc mangle táblájában közvetlenül a DNAT előtt valósulnak meg. A politikák szokásos sorrendje (order) itt nem érvényesül, mivel ezen politikák alkalmazása sokkal korábban történik a forgalom feldolgozási útján. Ennek ellenére a preDNAT politikák megtartják a saját sorrendi alkalmazásukat (order) egymás között.
A pre-DNAT politikák létrehozásakor fontos figyelmet fordítani arra a forgalomra, amelyet szeretne kezelni, és lehetővé tenni a többség elutasítását. Az 'allow' címkével megjelölt forgalom a pre-DNAT politikában már nem lesz ellenőrizve a hostendpoint politikán, míg a pre-DNAT politika kudarcával a forgalom továbbhalad a többi láncon.
A Calico kötelezővé tette az applyOnForward opció engedélyezését, amikor preDNAT-ot használnak, mivel a forgalom végpontja még nem lett kiválasztva definíció szerint. A forgalom a hosztfolyamatra, vagy podra, vagy egy másik csomópont irányába is terelhető.
Untracked Politika (5)
A hálózatok és alkalmazások viselkedésében jelentős eltérések lehetnek. Néhány szélsőséges esetben az alkalmazások sok rövid távú kapcsolatot generálhatnak. Ez conntrack (a Linux hálózati stack alapvető összetevője) memóriagondokat okozhat. Hagyományosan egy ilyen típusú alkalmazás futtatásához Linuxban kézzel kellett konfigurálni vagy letiltani a conntracket, vagy iptables szabályokat írni a conntrack megkerülésére. Az untracked policy a Calico-ban egy egyszerűbb és hatékonyabb lehetőség, ha maximálisan gyorsan szeretné kezelni a kapcsolatokat. Például ha egy masszív vagy mint kiegészítő védelmi intézkedés a .
Olvassa el ezt a SysWOW64 ) a további információkért, beleértve a teljesítményteszteket is az untracked policy használatával.
Amikor a Calico globalNetworkPolicy-ban az „doNotTrack: true” opciót adja meg, ez egy **nem nyomon követhető** politikává válik, és a Linux csomagkezelési folyamatának legkorábbi szakaszában alkalmazzák. Ha megnézzük a fenti diagramot, az untracked politikák az PREROUTING és OUTPUT láncokban alkalmazódnak a raw táblázatban, mielőtt a kapcsolatkövetés (conntrack) elindulna. Amikor egy csomagot az untracked politika engedélyez, az meg van jelölve, hogy letiltsa a kapcsolat követését erre a csomagra. Ez azt jelenti:
- Az untracked politika minden csomagra vonatkozik. Nincs kapcsolat (vagy áram). A kapcsolatok hiánya (connection) számos fontos következménnyel jár:
- Ha egyszerre szeretné engedélyezni a lekérdezési és válaszforgalmat, szüksége van szabályra mind a bejövő, mind a kimenő forgalomra (mivel a Calico általában a conntracket használja, hogy a válaszforgalmat engedélyezettként jelölje meg).
- Az untracked politika nem működik a Kubernetes munkaterhelésekkel (pod-okkal), mivel ebben az esetben nincs mód az outgoing kapcsolat nyomon követésére a pod-ból.
- A NAT nem működik helyesen a nem nyomon követhető csomagokkal (mivel a kernel a NAT leképezést a conntrackben tárolja).
- A „mindent engedélyező” szabályon keresztül haladva az untracked politikában minden csomagot nem nyomon követhetőként jelölnek meg. Ez szinte mindig nem azt jelenti, amit szeretne, ezért fontos, hogy nagyon szelektívek legyenek a nem nyomon követett politikák által engedélyezett csomagokkal (és lehetővé kell tenni a forgalom nagyobb részét, hogy normál nyomon követett politikákon keresztül haladhasson).
- Az untracked politikák a csomagfeldolgozási folyamat leges legelső szakaszában érvényesülnek. Ezt fontos megérteni a Calico politikák létrehozásakor. Lehet egy politikád pod számára order:1 értékkel és egy untracked politikád order:1000 értékkel. Ez azonban nem számít. Az untracked politika alkalmazásra kerül a pod politikája előtt. Az untracked politikák közötti végrehajtási sorrendet kizárólag a saját maguk között tartják be.
Mivel a doNotTrack politika egyik célja, hogy kényszerítse a politika korai alkalmazását a Linux csomagfeldolgozó folyamatában, a Calico kötelezővé teszi az applyOnForward opció megadását a doNotTrack használatakor. Ha megnézzük a csomagfeldolgozási diagramot, észrevehetjük, hogy az untracked politika (5) a route döntések előtt alkalmazásra kerül. A forgalom irányulhat a gazda-folyamatra, vagy átirányítható egy podra vagy egy másik csomópontba.
Összegzés
Megvizsgáltuk a Calico politikák különböző opcióit (host endpoint, applyOnForward, preDNAT, és untracked), és hogyan alkalmazzák ezeket a csomagfeldolgozásban. A működésük lényegének megértése segít hatékony és biztonságos politikák kidolgozásában. A Calico segítségével globális hálózati politikát alkalmazhatsz, amely címkékhöz (csomópontok és podok csoportjaihoz) érvényes, és különböző paraméterekkel rendelkező politikákat alkalmazhatsz. Ez lehetővé teszi a biztonsági szakemberek és a hálózat tervezők számára, hogy egyszerűen védjék az összes endpoint típust egyetlen politikai nyelven a Calico politikák segítségével.
Köszönetnyilvánítás: Szeretném megköszönni és az ő átnézésükért és értékes információikért.
Forrás: habr.com
