Plugin sieciowy Calico oferuje szeroki zestaw polityk sieciowych z ujednoliconą składnią do zabezpieczania hostów na sprzęcie, maszynach wirtualnych oraz podach. Polityki te mogą być stosowane w ramach namespace lub jako ogólne polityki sieciowe, które mają zastosowanie do (do ochrony aplikacji działających bezpośrednio na hoście — hostem może być bezpośrednio serwer lub maszyna wirtualna) lub do (do ochrony aplikacji działających w kontenerach lub maszynach wirtualnych umieszczonych na hoście). Polityki Calico umożliwiają wprowadzenie środków bezpieczeństwa dla różnych punktów przepływu pakietów z pomocą takich parametrów jak preDNAT, unraracked i applyOnForward. Zrozumienie, jak te opcje działają, może pomóc zwiększyć bezpieczeństwo i wydajność systemu jako całości. W tym artykule wyjaśniono istotę tych parametrów polityk Calico (preDNAT, unraracked i applyOnForward), stosowanych do endpointów hostów, z naciskiem na to, co dzieje się w ścieżkach przetwarzania pakietów (łańcuchach iptables).
Artykuł ten zakłada, że masz podstawową wiedzę na temat zasad działania polityk sieciowych Kubernetes i Calico. Jeśli nie, zalecamy zapoznanie się z i korzystając z Calico, zanim przeczytasz ten artykuł. Oczekujemy również, że masz podstawową wiedzę na temat działania systemu Linux.
Calico pozwala na zastosowanie zestawu zasad dostępu według etykiet (do grup hostów oraz workloadów/podów). Jest to bardzo przydatne, jeśli korzystasz z różnorodnych systemów — maszyn wirtualnych, systemu bezpośrednio na sprzęcie lub infrastruktury Kubernetes. Ponadto możesz chronić swój klaster (węzły) za pomocą zestawu deklaratywnych polityk i stosować polityki sieciowe do ruchu przychodzącego (na przykład przez usługę NodePorts lub adresy IP zewnętrzne).
Na poziomie fundamentalnym, gdy Calico łączy pod z siecią (zobacz diagram poniżej), łączy go z hostem za pomocą wirtualnego interfejsu Ethernet (veth). Ruch wysyłany przez pod przychodzi na hosta z tego wirtualnego interfejsu i jest obsługiwany tak, jakby pochodził z fizycznego interfejsu sieciowego. Domyślnie Calico nazywa te interfejsy caliXXX. Ponieważ ruch przechodzi przez wirtualny interfejs, przechodzi przez iptables tak, jakby pod znajdował się w odległości jednego hopa. Dlatego, gdy ruch przychodzi/opuszcza pod, jest on przekazywany (forwarded) z perspektywy hosta.
Na węźle Kubernetes, na którym działa Calico, możesz powiązać wirtualny interfejs (veth) z obciążeniem w następujący sposób. W poniższym przykładzie możesz zobaczyć, że veth#10 (calic1cbf1ca0f8) jest połączony z cnx-manager-* w przestrzeni nazw 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
... 
Biorąc pod uwagę, że Calico tworzy interfejs veth dla każdego obciążenia, jak stosuje polityki? W tym celu Calico tworzy haki w różnych łańcuchach procesów pakietów, używając iptables.
Na diagramie poniżej przedstawiono łańcuchy biorące udział w przetwarzaniu pakietów w iptables (lub podsystemie netfilter). Gdy pakiet przychodzi przez interfejs sieciowy, najpierw przechodzi przez łańcuch PREROUTING. Następnie podejmowana jest decyzja o routingu, a na jej podstawie pakiet przechodzi albo przez INPUT (skierowany na procesy hosta), albo przez FORWARD (skierowany do pod lub innego węzła w sieci). Z lokalnego procesu pakiet przechodzi przez łańcuch OUTPUT, a następnie POSTROUTING przed wysłaniem go kablem.
Zauważ, że pod również jest zewnętrznym obiektem (połączonym z veth) z punktu widzenia przetwarzania iptables. Podsumujmy:
- Przekazywany (forwarded) ruch (nat, routowany lub w/ze pod) przechodzi przez łańcuchy PREROUTING — FORWARD — POSTROUTING.
- Ruch do lokalnego procesu hosta przechodzi przez łańcuch PREROUTING — INPUT.
- Ruch z lokalnego procesu hosta przechodzi przez łańcuch OUTPUT — POSTROUTING.
Calico oferuje opcje polityki, dzięki którym można stosować polityki do wszystkich łańcuchów. Mając to na uwadze, przyjrzyjmy się różnym opcjom konfiguracji polityk dostępnych w Calico. Numery na liście poniżej odpowiadają numerom na powyższej diagramie.
- Polityka punktów końcowych ładunku (pod)
- Polityka punktów końcowych hosta
- Opcja ApplyOnForward
- Polityka PreDNAT
- Polityka Untracked
Zacznijmy od omówienia, jak polityki są stosowane do punktów końcowych ładunku (podów Kubernetes lub VM OpenStack), a następnie przyjrzymy się opcjom polityk dla punktów końcowych hosta.
Punkty końcowe ładunku
Polityka punktów końcowych ładunku (1)
To opcja zabezpieczająca Twoje pod'y Kubernetes. W Calico obsługiwane są polityki Kubernetes NetworkPolicy, ale także oferuje dodatkowe polityki — Calico NetworkPolicy i GlobalNetworkPolicy. Calico tworzy łańcuch dla każdego pod'a (ładunku) i wtyczki do łańcuchów INPUT i OUTPUT dla ładunku do tabeli filtrów w łańcuchu FORWARD.
Punkty końcowe hosta
Polityka punktów końcowych hosta (2)
Oprócz CNI (interfejsu sieci kontenerów), polityki Calico zapewniają możliwość zabezpieczenia samego hosta. W Calico możesz utworzyć punkt końcowy hosta, określając kombinację interfejsu hosta oraz, w razie potrzeby, numerów portów. Stosowanie polityk do tego bytu osiąga się poprzez tabele filtrów w łańcuchach INPUT i OUTPUT. Jak widać na diagramie, (2) są one stosowane do lokalnych procesów na nodzie/hoście. Oznacza to, że jeśli stworzysz politykę, która ma zastosowanie do punktu końcowego hosta, nie wpłynie ona na ruch przychodzący/wychodzący z twoich pod'ów. Jednak dzięki niej zapewniony jest jednolity interfejs/składnia do blokowania ruchu dla twojego hosta i pod'ów za pomocą polityk Calico. Znacznie upraszcza to zarządzanie politykami w heterogenicznej sieci. Konfiguracja polityk punktów końcowych hosta w celu wzmocnienia zabezpieczeń klastra to jeszcze jeden istotny przypadek ich zastosowania.
Polityka ApplyOnForward (3)
Opcja ApplyOnForward jest dostępna w calico globalnej polityce sieciowej, aby umożliwić stosowanie polityk do całego ruchu przechodzącego przez punkt końcowy hosta, w tym ruchu, który będzie przekierowywany przez hosta (forwarded). Ten ruch obejmuje przesyłany do lokalnego pod'a lub gdziekolwiek indziej w sieci. Calico wymaga, aby ta opcja była włączona dla polityk korzystających z PreDNAT i untracked, patrz następne sekcje. Ponadto, ApplyOnForward można używać do śledzenia ruchu hosta w przypadkach korzystania z wirtualnego routera lub programowego NAT.
Zauważ, że jeśli musisz zastosować tę samą politykę sieciową zarówno dla procesów hosta, jak i dla podów, nie musisz używać opcji ApplyOnForward. Wystarczy stworzyć etykietę dla potrzebnych hostendpoint i workload endpoint (pod). Calico jest na tyle inteligentne, aby stosować politykę na podstawie etykiet, niezależnie od typu punktu końcowego (hostendpoint lub workload).
Polityka PreDNAT (4)
W Kubernetes porty obiektu service mogą być przekierowane na zewnątrz za pomocą opcji NodePorts lub opcjonalnie (przy użyciu Calico) przez ich zgłoszenie przez opcje Cluster IPs lub External IPs. Kube-proxy równoważy ruch przychodzący przypisany do service do podów odpowiednich service, używając DNAT. Mając to na uwadze, jak zastosować polityki dla ruchu przychodzącego przez NodePorts? Aby te polityki zostały zastosowane przed przetworzeniem ruchu przez DNAT (które jest mapowaniem hosta:port do odpowiedniego service), Calico oferuje parametr dla globalNetworkPolicy o nazwie „preDNAT: true”.
Kiedy pre-DNAT jest włączony, te polityki są wdrażane w (4) na diagramie — w tabeli mangle łańcucha PREROUTING — bezpośrednio przed DNAT. Zwykła kolejność polityk (order) nie jest tutaj przestrzegana, ponieważ zastosowanie tych polityk następuje znacznie wcześniej w drodze przetwarzania ruchu. Niemniej jednak polityki preDNAT przestrzegają kolejności zastosowania (order) między sobą.
Podczas tworzenia polityk z pre-DNAT ważne jest, aby zwrócić uwagę na ruch, który chcesz przetwarzać, i pozwolić większości być odrzuconej. Ruch oznaczony jako ‘allow’ w polityce pre-DNAT nie będzie już sprawdzany przez politykę hostendpoint, podczas gdy ruch, który nie przejdzie polityki pre-DNAT, będzie kontynuował swoje przejście przez pozostałe łańcuchy.
Calico uczyniło obowiązkowym włączenie opcji applyOnForward przy użyciu preDNAT, ponieważ z definicji miejsce przeznaczenia ruchu nie zostało jeszcze wybrane. Ruch może być skierowany na proces hosta lub może być przekierowany na pod lub na inny węzeł.
Polityka Untracked (5)
Sieci i aplikacje mogą różnić się znacznie w swoim zachowaniu. W niektórych skrajnych przypadkach aplikacje mogą generować wiele krótkotrwałych połączeń. Może to prowadzić do braku pamięci w conntrack (podstawowym składniku stosu sieciowego Linux). Tradycyjnie, aby uruchomić takie aplikacje w Linuxie, trzeba ręcznie skonfigurować lub wyłączyć conntrack, lub napisać reguły iptables, aby ominąć conntrack. Polityka untracked w Calico to prostsza i bardziej skuteczna opcja, jeśli chcesz szybko obsługiwać połączenia. Na przykład, jeśli używasz masowego lub jako dodatkowa warstwa ochrony przed .
Przeczytaj ten (lub ) aby uzyskać więcej informacji, w tym testy wydajności przy użyciu polityki untracked.
Kiedy ustawiasz opcję „doNotTrack: true” w Calico globalNetworkPolicy, staje się ona **nieotwieralną** polityką i jest stosowana na najwcześniejszym etapie przetwarzania pakietów w Linuxie. Patrząc na powyższy diagram, polityki untracked są stosowane w łańcuchach PREROUTING i OUTPUT w tabeli raw, zanim rozpocznie się śledzenie połączeń (conntrack). Gdy pakiet zostanie zezwolony przez politykę untracked, zostaje oznaczony, aby wyłączyć śledzenie połączenia dla tego pakietu. Oznacza to:
- Polityka untracked stosowana jest do każdego pakietu. Nie ma pojęcia połączenia (ani strumienia). Brak połączeń pociąga za sobą kilka istotnych konsekwencji:
- Jeśli chcesz zezwolić zarówno na ruch żądań, jak i na ruch odpowiedzi, musisz mieć regułę zarówno dla przychodzącego, jak i wychodzącego (ponieważ Calico zwykle używa conntrack, aby oznaczyć ruch odpowiedzi jako zezwolony).
- Polityka untracked nie działa dla obciążenia roboczego Kubernetes (pod’ów), ponieważ w tym przypadku nie ma sposobu na śledzenie wychodzącego połączenia z poda.
- NAT działa nieprawidłowo z nieotwieralnymi pakietami (ponieważ jądro przechowuje mapowanie NAT w conntrack).
- Przy przechodzeniu przez regułę „zezwól na wszystko” w polityce untracked wszystkie pakiety będą oznaczane jako nieotwieralne. To prawie zawsze nie jest to, czego potrzebujesz, dlatego ważne jest, aby być bardzo wybrednym w stosunku do pakietów zezwolonych przez polityki untracked (i pozwalać większej części ruchu przechodzić przez zwykłe polityki śledzone).
- Polityki untracked są stosowane na samym początku procesu przetwarzania pakietów. To jest bardzo ważne do zrozumienia przy tworzeniu polityk Calico. Możesz mieć politykę dla poda z order:1 i politykę untracked z order:1000. Nie będzie to miało znaczenia. Polityka untracked zostanie zastosowana przed polityką dla poda. Polityki untracked przestrzegają kolejności wykonania tylko między sobą.
Ponieważ jednym z celów polityki doNotTrack jest wymuszenie zastosowania polityki na najwcześniejszym etapie przetwarzania pakietów w systemie Linux, Calico wymaga wskazania opcji applyOnForward przy korzystaniu z doNotTrack. Odnosząc się do diagramu przetwarzania pakietów, zwróć uwagę, że polityka untracked (5) jest stosowana przed jakimikolwiek decyzjami o trasowaniu. Ruch może być kierowany do procesu-host, lub może być przekierowywany do poda lub innego węzła.
Podsumowanie
Przeanalizowaliśmy różne opcje polityk (Host endpoint, ApplyOnForward, preDNAT, i Untracked) w Calico i jak są one stosowane w ścieżce przetwarzania pakietów. Zrozumienie ich działania pomaga w opracowywaniu skutecznych i bezpiecznych polityk. Dzięki Calico możesz używać globalnej polityki sieciowej, która jest stosowana do etykiet (grupy węzłów i podów) oraz stosować polityki z różnymi parametrami. Umożliwia to specjalistom ds. bezpieczeństwa i projektowania sieci wygodne zabezpieczenie „wszystkiego” (typy endpointów) za pomocą jednego języka polityk z politykami Calico.
Podziękowania: Chciałbym podziękować i za ich przegląd i cenne informacje.
Źródło: habr.com
