Zrozumienie opcji polityki sieciowej w Calico

Wtyczka sieciowa Calico zapewnia szeroką gamę zasad sieciowych z ujednoliconą składnią w celu ochrony hostów sprzętowych, maszyn wirtualnych i podów. Te zasady mogą być stosowane w obrębie przestrzeni nazw lub mogą być globalnymi zasadami sieciowymi, które mają zastosowanie punkt końcowy hosta (w celu ochrony aplikacji działających bezpośrednio na hoście - hostem może być serwer lub maszyna wirtualna) lub punkt końcowy obciążenia (w celu ochrony aplikacji działających w kontenerach lub hostowanych maszynach wirtualnych). Zasady Calico umożliwiają zastosowanie środków bezpieczeństwa w różnych punktach ścieżki pakietu przy użyciu opcji takich jak preDNAT, Unraracked i ApplyOnForward. Zrozumienie działania tych opcji może pomóc w poprawie bezpieczeństwa i wydajności całego systemu. W tym artykule wyjaśniono istotę opcji polityki Calico (preDNAT, unraracked i ApplyOnForward) stosowanych do punktów końcowych hosta, z naciskiem na to, co dzieje się w ścieżkach przetwarzania pakietów (łańcuchy iptabels).

W tym artykule założono, że masz podstawową wiedzę na temat działania zasad sieciowych Kubernetes i Calico. Jeśli nie, zalecamy wypróbowanie podstawowy samouczek dotyczący zasad sieci и poradnik dotyczący ochrony hosta używając Calico przed przeczytaniem tego artykułu. Oczekujemy również, że będziesz mieć podstawową wiedzę na temat pracy iptables w Linuksie.

Perkal globalna polityka sieciowa umożliwia zastosowanie zestawu reguł dostępu według etykiet (do grup hostów i obciążeń/podów). Jest to bardzo przydatne, jeśli razem korzystacie z systemów heterogenicznych – maszyn wirtualnych, systemu bezpośrednio na sprzęcie lub infrastruktury kubernetes. Ponadto możesz chronić swój klaster (węzły) za pomocą zestawu zasad deklaratywnych i stosować zasady sieciowe do ruchu przychodzącego (na przykład za pośrednictwem usługi NodePorts lub Zewnętrzne adresy IP).

Na podstawowym poziomie, gdy Calico podłącza moduł do sieci (patrz diagram poniżej), łączy go z hostem za pomocą wirtualnego interfejsu Ethernet (veth). Ruch wysyłany przez poda przychodzi do hosta z tego wirtualnego interfejsu i jest przetwarzany w taki sam sposób, jakby pochodził z fizycznego interfejsu sieciowego. Domyślnie Calico nazywa te interfejsy caliXXX. Ponieważ ruch przechodzi przez interfejs wirtualny, przechodzi przez iptables tak, jakby kapsuła była o krok dalej. Dlatego też, gdy ruch przychodzi do/z kapsuły, jest on przekazywany z punktu widzenia hosta.

W węźle Kubernetes z systemem Calico możesz zmapować interfejs wirtualny (veth) na obciążenie w następujący sposób. W poniższym przykładzie widać, że veth#10 (calic1cbf1ca0f8) jest podłączony do cnx-manager-* w przestrzeni nazw 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
...

Biorąc pod uwagę, że Calico tworzy własny interfejs dla każdego obciążenia, w jaki sposób egzekwuje zasady? Aby to zrobić, Calico tworzy zaczepy w różnych łańcuchach ścieżki przetwarzania pakietów za pomocą iptables.

Poniższy diagram przedstawia łańcuchy biorące udział w przetwarzaniu pakietów w iptables (lub podsystemie netfilter). Kiedy pakiet dociera przez interfejs sieciowy, najpierw przechodzi przez łańcuch PREROUTING. Następnie podejmowana jest decyzja o routingu i na tej podstawie pakiet przechodzi albo przez wejście INPUT (skierowany do procesów hosta), albo FORWARD (skierowany do kapsuły lub innego węzła w sieci). Z procesu lokalnego pakiet przechodzi przez łańcuch OUTPUT, a następnie POSTROUTING, zanim zostanie wysłany kablem.

Zauważ, że kapsuła jest także jednostką zewnętrzną (połączoną z veth) w zakresie przetwarzania iptables. Podsumujmy:

• Ruch przekazywany (nat, routowany lub do/z podu) przechodzi przez łańcuchy PREROUTING - FORWARD - POSTROUTING.
• Ruch do lokalnego procesu hosta przechodzi przez łańcuch PREROUTING - INPUT.
• Ruch z procesu lokalnego hosta przechodzi przez łańcuch OUTPUT - POSTROUTING.

Calico udostępnia opcje zasad, które umożliwiają stosowanie zasad we wszystkich sieciach. Mając to na uwadze, przyjrzyjmy się różnym opcjom konfiguracji zasad dostępnych w Calico. Liczby na poniższej liście opcji odpowiadają liczbom na powyższym schemacie.

1. Zasady punktu końcowego obciążenia (pod).
2. Zasady punktu końcowego hosta
3. Opcja ApplyOnForward
4. Polityka PreDNAT
5. Nieśledzona polityka

Zacznijmy od sprawdzenia, w jaki sposób zasady są stosowane do punktów końcowych obciążenia (podów Kubernetes lub maszyn wirtualnych OpenStack), a następnie przyjrzyjmy się opcjom zasad dla punktów końcowych hosta.

Punkty końcowe obciążenia

Zasady dotyczące punktu końcowego obciążenia (1)

Jest to opcja chroniąca Twoje pody Kubernetes. Calico obsługuje współpracę z Kubernetes NetworkPolicy, ale udostępnia także dodatkowe zasady – Calico NetworkPolicy i GlobalNetworkPolicy. Calico tworzy łańcuch dla każdego zasobnika (obciążenie) i zaczepia łańcuchy INPUT i OUTPUT dla obciążenia do tabeli filtrów łańcucha FORWARD.

Punkty końcowe hosta

Zasady punktu końcowego hosta (2)

Oprócz CNI (kontenerowego interfejsu sieciowego) zasady Calico zapewniają możliwość ochrony samego hosta. W Calico możesz utworzyć punkt końcowy hosta, określając kombinację interfejsu hosta i, jeśli to konieczne, numerów portów. Egzekwowanie zasad dla tej jednostki odbywa się za pomocą tabeli filtrów w łańcuchach INPUT i OUTPUT. Jak widać na diagramie (2) dotyczą one procesów lokalnych na węźle/hoście. Oznacza to, że jeśli utworzysz zasady mające zastosowanie do punktu końcowego hosta, nie będzie to miało wpływu na ruch przychodzący i wychodzący z Twoich podów. Zapewnia jednak pojedynczy interfejs/składnię do blokowania ruchu dla hosta i kapsuł za pomocą zasad Calico. To znacznie upraszcza proces zarządzania politykami dla sieci heterogenicznej. Konfigurowanie zasad punktu końcowego hosta w celu zwiększenia bezpieczeństwa klastra to kolejny ważny przypadek użycia.

Polityka ApplyOnForward (3)

Opcja ApplyOnForward jest dostępna w globalnych zasadach sieci Calico, aby umożliwić stosowanie zasad do całego ruchu przechodzącego przez punkt końcowy hosta, w tym ruchu, który będzie przekazywany przez hosta. Obejmuje to ruch przekazywany do lokalnego poda lub gdziekolwiek indziej w sieci. Calico wymaga włączenia tego ustawienia w przypadku zasad korzystających z PreDNAT i nieśledzonych, zobacz poniższe sekcje. Ponadto ApplyOnForward może służyć do monitorowania ruchu hosta w przypadkach, gdy używany jest router wirtualny lub programowy NAT.

Pamiętaj, że jeśli chcesz zastosować tę samą politykę sieciową zarówno do procesów hosta, jak i podów, nie musisz używać opcji ApplyOnForward. Wszystko, co musisz zrobić, to utworzyć etykietę dla wymaganego punktu końcowego hosta i punktu końcowego obciążenia (pod). Calico jest wystarczająco inteligentny, aby egzekwować zasady w oparciu o etykiety, niezależnie od typu punktu końcowego (punkt końcowy hosta lub obciążenie).

Polityka PreDNAT (4)

W Kubernetes porty jednostek usługowych można udostępnić na zewnątrz za pomocą opcji NodePorts lub opcjonalnie (w przypadku korzystania z Calico) poprzez anonsowanie ich przy użyciu opcji IP klastra lub Zewnętrznych adresów IP. Kube-proxy równoważy ruch przychodzący związany z usługą z zasobnikami odpowiedniej usługi za pomocą DNAT. Biorąc to pod uwagę, jak egzekwować zasady dotyczące ruchu przychodzącego przez NodePorts? Aby mieć pewność, że te zasady zostaną zastosowane przed przetworzeniem ruchu przez DNAT (co jest mapowaniem między hostem:portem a odpowiednią usługą), Calico udostępnia parametr globalNetworkPolicy o nazwie „preDNAT: true”.

Gdy włączone jest pre-DNAT, polityki te są implementowane w (4) na schemacie – w tabeli mangle łańcucha PREROUTING – bezpośrednio przed DNAT. Nie jest tu zachowana zwykła kolejność polityk, ponieważ zastosowanie tych polityk następuje znacznie wcześniej na ścieżce przetwarzania ruchu. Jednakże zasady preDNAT przestrzegają kolejności stosowania między sobą.

Tworząc zasady z pre-DNAT, ważne jest, aby zachować ostrożność w zakresie ruchu, który chcesz przetworzyć, i pozwolić, aby większość została odrzucona. Ruch oznaczony jako „zezwól” w polityce przed DNAT nie będzie już sprawdzany przez politykę punktu końcowego hosta, natomiast ruch, który nie spełni zasad przed DNAT, będzie kontynuowany w pozostałych łańcuchach.
Firma Calico wprowadziła obowiązek włączenia opcji ApplyOnForward podczas korzystania z preDNAT, ponieważ z definicji miejsce docelowe ruchu nie zostało jeszcze wybrane. Ruch może być kierowany do procesu hosta lub do poda lub innego węzła.

Nieśledzone zasady (5)

Sieci i aplikacje mogą wykazywać duże różnice w zachowaniu. W niektórych skrajnych przypadkach aplikacje mogą generować wiele krótkotrwałych połączeń. Może to spowodować, że w Conntrack (głównym składniku stosu sieciowego Linuksa) zabraknie pamięci. Tradycyjnie, aby uruchomić tego typu aplikacje w systemie Linux, trzeba ręcznie skonfigurować lub wyłączyć conntrack albo napisać reguły iptables w celu ominięcia Conntrack. Polityka nieśledzona w Calico to prostsza i wydajniejsza opcja, jeśli chcesz przetwarzać połączenia tak szybko, jak to możliwe. Na przykład, jeśli używasz masywnego memcache lub jako dodatkowy środek ochrony przed DDOS.

Przeczytaj to blogu (or nasze tłumaczenie), aby uzyskać więcej informacji, w tym testy wydajności przy użyciu zasad nieśledzonych.

Gdy ustawisz opcję „doNotTrack: true” w Calico globalNetworkPolicy, staje się ona polityką **nieśledzoną** i jest stosowana na bardzo wczesnym etapie potoku przetwarzania pakietów Linuksa. Patrząc na powyższy diagram, nieśledzone zasady są stosowane w łańcuchach PREROUTING i OUTPUT w tabeli surowej przed rozpoczęciem śledzenia połączenia (conntrack). Jeśli zasada nieśledzenia zezwala na pakiet, jest on zaznaczany w celu wyłączenia śledzenia połączenia dla tego pakietu. To znaczy:

• Polityka nieśledzonego jest stosowana dla poszczególnych pakietów. Nie ma koncepcji połączenia (lub przepływu). Brak połączeń ma kilka ważnych konsekwencji:
• Jeśli chcesz zezwolić zarówno na ruch żądań, jak i odpowiedzi, potrzebujesz reguły zarówno dla ruchu przychodzącego, jak i wychodzącego (ponieważ Calico zazwyczaj używa funkcji conntrack do oznaczania ruchu odpowiedzi jako dozwolonego).
• Polityka nieśledzona nie działa w przypadku obciążeń Kubernetes (podów), ponieważ w tym przypadku nie ma możliwości śledzenia połączenia wychodzącego z poda.
• NAT nie działa poprawnie z nieśledzonymi pakietami (ponieważ jądro przechowuje mapowanie NAT w conntrack).
• Po przejściu przez regułę „zezwól na wszystko” w polityce nieśledzonej wszystkie pakiety zostaną oznaczone jako nieśledzone. Prawie zawsze nie jest to zgodne z oczekiwaniami, dlatego ważne jest, aby bardzo selektywnie wybierać pakiety dozwolone w ramach zasad nieśledzonych (i zezwalać większości ruchu na przechodzenie przez zwykłe zasady śledzone).
• Zasady nieśledzone są stosowane na samym początku potoku przetwarzania pakietów. Jest to bardzo ważne, aby zrozumieć podczas tworzenia polityk Calico. Możesz mieć politykę podów z zamówieniem: 1 i politykę nieśledzone z zamówieniem: 1000. To nie będzie miało znaczenia. Zasada Nieśledzone zostanie zastosowana przed zasadą dotyczącą zasobnika. Nieśledzone zasady szanują kolejność wykonywania tylko między sobą.

Ponieważ jednym z celów polityki doNotTrack jest egzekwowanie jej na bardzo wczesnym etapie przetwarzania pakietów w systemie Linux, Calico nakłada obowiązek określenia opcji ApplyOnForward podczas korzystania z doNotTrack. Odnosząc się do diagramu przetwarzania pakietów, zauważ, że polityka untracked(5) jest stosowana przed podjęciem jakichkolwiek decyzji o routingu. Ruch może być kierowany do procesu hosta lub do poda lub innego węzła.

Wyniki

Przyjrzeliśmy się różnym opcjom zasad (punkt końcowy hosta, ApplyOnForward, preDNAT i Untracked) w Calico oraz sposobom ich stosowania na ś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 ma zastosowanie do etykiety (grupy węzłów i podów) oraz stosować polityki z różnymi parametrami. Dzięki temu specjaliści ds. bezpieczeństwa i projektowania sieci mogą wygodnie chronić „wszystko” (typy punktów końcowych) jednocześnie, korzystając z jednego języka zasad z politykami Calico.

Podziękowanie: Chciałbym podziękować Seana Cramptona и Aleksa Pollitta za ich recenzję i cenne informacje.

Źródło: www.habr.com