Разбиране на опциите за прилагане на мрежова политика с Calico

Мрежовият плъгин Calico предоставя широк набор от мрежови политики с унифициран синтаксис за защита на хардуерни хостове, виртуални машини и подове. Тези политики могат да бъдат приложени в рамките на пространство от имена или да бъдат глобални мрежови политики, които се прилагат към крайна точка на хост (за защита на приложения, работещи директно на хоста - хостът може да бъде сървър или виртуална машина) или крайна точка на работното натоварване (за защита на приложения, работещи в контейнери или хоствани виртуални машини). Политиките на Calico ви позволяват да прилагате мерки за сигурност в различни точки от пътя на пакета, като използвате опции като preDNAT, unracked и applyOnForward. Разбирането как работят тези опции може да помогне за подобряване на сигурността и производителността на цялостната ви система. Тази статия обяснява същността на тези опции на правилата на Calico (preDNAT, unracked и applyOnForward), приложени към крайните точки на хоста, с акцент върху това, което се случва в пътищата за обработка на пакети (вериги iptabels).

Тази статия предполага, че имате основно разбиране за това как работят мрежовите политики на Kubernetes и Calico. Ако не, препоръчваме да опитате урок за основна мрежова политика и урок за защита на хоста използвайки Calico, преди да прочетете тази статия. Освен това очакваме да имате основни познания за работата IPTABLES в linux.

американ глобална мрежова политика ви позволява да прилагате набор от правила за достъп по етикети (към групи от хостове и работни натоварвания/подове). Това е много полезно, ако използвате хетерогенни системи заедно - виртуални машини, система директно върху хардуер или kubernetes инфраструктура. Освен това можете да защитите своя клъстер (възли) с помощта на набор от декларативни политики и да приложите мрежови политики към входящия трафик (например чрез услугата NodePorts или външни IP адреси).

На основно ниво, когато Calico свързва под към мрежата (вижте диаграмата по-долу), той го свързва с хоста, използвайки виртуален Ethernet интерфейс (veth). Трафикът, изпратен от pod, идва към хоста от този виртуален интерфейс и се обработва по същия начин, както ако идва от физически мрежов интерфейс. По подразбиране Calico нарича тези интерфейси caliXXX. Тъй като трафикът идва през виртуалния интерфейс, той преминава през iptables, сякаш подът е на един скок разстояние. Следователно, когато трафикът идва към/от под, той се препраща от гледна точка на хоста.

На Kubernetes възел, изпълняващ Calico, можете да нанесете виртуален интерфейс (veth) на работно натоварване, както следва. В примера по-долу можете да видите, че veth#10 (calic1cbf1ca0f8) е свързан към cnx-manager-* в пространството от имена на 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
...

Като се има предвид, че Calico създава veth интерфейс за всяко работно натоварване, как налага политики? За да направи това, Calico създава куки в различни вериги на пътя за обработка на пакети, използвайки iptables.

Диаграмата по-долу показва веригите, включени в обработката на пакети в iptables (или подсистемата netfilter). Когато пакет пристигне през мрежов интерфейс, той първо преминава през веригата PREROUTING. След това се взема решение за маршрутизиране и въз основа на това пакетът преминава през INPUT (насочен към хост процесите) или FORWARD (насочен към pod или друг възел в мрежата). От локалния процес пакетът преминава през веригата OUTPUT и след това POSTROUTING, преди да бъде изпратен надолу по кабела.

Имайте предвид, че pod също е външен обект (свързан с veth) по отношение на обработката на iptables. Нека обобщим:

• Пренасоченият трафик (nat, маршрутизиран или към/от под) преминава през веригите PREROUTING - FORWARD - POSTROUTING.
• Трафикът към локалния хост процес преминава през веригата PREROUTING - INPUT.
• Трафикът от локалния хост процес преминава през веригата OUTPUT - POSTROUTING.

Calico предоставя опции за политики, които ви позволяват да прилагате политики във всички вериги. Имайки предвид това, нека да разгледаме различните опции за конфигуриране на политики, налични в Calico. Числата в списъка с опции по-долу съответстват на числата в диаграмата по-горе.

1. Правила за крайна точка (pod) на работното натоварване
2. Политика за крайни точки на хоста
3. Опция ApplyOnForward
4. PreDNAT политика
5. Непроследена политика

Нека започнем, като разгледаме как се прилагат правилата към крайните точки на работното натоварване (Kubernetes pods или OpenStack VM), а след това разгледаме опциите на правилата за крайните точки на хоста.

Крайни точки на работното натоварване

Правила за крайна точка на натоварване (1)

Това е опция за защита на вашите модули kubernetes. Calico поддържа работа с Kubernetes NetworkPolicy, но предоставя и допълнителни политики - Calico NetworkPolicy и GlobalNetworkPolicy. Calico създава верига за всеки pod (работно натоварване) и свързва веригите INPUT и OUTPUT за работното натоварване към филтърната таблица на веригата FORWARD.

Хост крайни точки

Правила за крайни точки на хост (2)

В допълнение към CNI (контейнер мрежов интерфейс), политиките на Calico предоставят възможност за защита на самия хост. В Calico можете да създадете крайна точка на хост, като посочите комбинация от интерфейс на хост и, ако е необходимо, номера на портове. Прилагането на политика за този обект се постига с помощта на филтърна таблица във веригите INPUT и OUTPUT. Както можете да видите от диаграмата, (2) те се прилагат за локални процеси на възела/хоста. Тоест, ако създадете политика, която се прилага към крайната точка на хоста, това няма да повлияе на трафика, отиващ към/от вашите капсули. Но предоставя единен интерфейс/синтаксис за блокиране на трафика за вашия хост и подове с помощта на политики на Calico. Това значително опростява процеса на управление на политики за разнородна мрежа. Конфигурирането на политики за крайна точка на хоста за подобряване на сигурността на клъстера е друг важен случай на използване.

Политика ApplyOnForward (3)

Опцията ApplyOnForward е налична в глобалната мрежова политика на Calico, за да позволи прилагането на политики към целия трафик, преминаващ през крайната точка на хоста, включително трафика, който ще бъде препратен от хоста. Това включва трафик, препратен към локалния модул или където и да е другаде в мрежата. Calico изисква тази настройка да бъде активирана за политики, използващи PreDNAT и непроследени, вижте следните раздели. Освен това ApplyOnForward може да се използва за наблюдение на трафика на хост в случаите, когато се използва виртуален рутер или софтуерен NAT.

Имайте предвид, че ако трябва да приложите една и съща мрежова политика както към хост процеси, така и към подове, тогава не е необходимо да използвате опцията ApplyOnForward. Всичко, което трябва да направите, е да създадете етикет за необходимата крайна точка на хост и крайна точка за работно натоварване (pod). Calico е достатъчно интелигентен, за да наложи политика въз основа на етикети, независимо от типа крайна точка (точка на хост или работно натоварване).

PreDNAT Политика (4)

В Kubernetes портовете на обслужващ обект могат да бъдат експонирани външно с помощта на опцията NodePorts или, по избор (когато използвате Calico), като ги рекламирате с помощта на опциите Cluster IPs или External IPs. Kube-proxy балансира входящия трафик, свързан с услуга, към подовете на съответната услуга, използвайки DNAT. Като се има предвид това, как налагате политики за трафик, идващ през NodePorts? За да гарантира, че тези политики се прилагат, преди трафикът да бъде обработен от DNAT (което е съпоставяне между хост:порт и съответната услуга), Calico предоставя параметър за globalNetworkPolicy, наречен "preDNAT: true".

Когато pre-DNAT е активиран, тези правила се прилагат в (4) на диаграмата - в таблицата на mangle на веригата PREROUTING - непосредствено преди DNAT. Тук не се следва обичайният ред на политиките, тъй като прилагането на тези политики се случва много по-рано в пътя за обработка на трафика. Политиките на preDNAT обаче спазват реда на прилагане помежду си.

Когато създавате политики с pre-DNAT, е важно да внимавате за трафика, който искате да обработите, и да позволите по-голямата част да бъде отхвърлена. Трафикът, маркиран като „разрешаване“ в политиката преди DNAT, вече няма да се проверява от политиката за крайната точка на хоста, докато трафикът, който не отговаря на политиката преди DNAT, ще продължи през останалите вериги.
Calico направи задължително активирането на опцията applyOnForward при използване на preDNAT, тъй като по дефиниция местоназначението на трафика все още не е избрано. Трафикът може да бъде насочен към хост процеса или може да бъде препратен към pod или друг възел.

Непроследена политика (5)

Мрежите и приложенията могат да имат големи разлики в поведението. В някои екстремни случаи приложенията могат да генерират много краткотрайни връзки. Това може да доведе до изчерпване на паметта на conntrack (основен компонент на мрежовия стек на Linux). Традиционно, за да стартирате тези видове приложения на Linux, ще трябва ръчно да конфигурирате или деактивирате conntrack или да напишете правила за iptables, за да заобиколите conntrack. Непроследената политика в Calico е по-проста и по-ефективна опция, ако искате да обработвате връзки възможно най-бързо. Например, ако използвате масивни MemCache или като допълнителна мярка за защита срещу DDOS.

Прочети това блог пост (Or нашият превод) за повече информация, включително тестове за ефективност, използващи непроследени правила.

Когато зададете опцията „doNotTrack: true“ в Calico globalNetworkPolicy, тя става **непроследена** политика и се прилага много рано в тръбопровода за обработка на пакети на Linux. Разглеждайки диаграмата по-горе, непроследените политики се прилагат във веригите PREROUTING и OUTPUT в необработената таблица, преди да започне проследяването на връзката (conntrack). Когато даден пакет е разрешен от непроследената политика, той се маркира, за да забрани проследяването на връзката за този пакет. Това означава:

• Непроследената политика се прилага за всеки пакет. Няма концепция за връзка (или поток). Липсата на връзки има няколко важни последици:
• Ако искате да разрешите както трафик на заявка, така и трафик на отговор, имате нужда от правило както за входящ, така и за изходящ (тъй като Calico обикновено използва conntrack, за да маркира трафика за отговор като разрешен).
• Непроследената политика не работи за работни натоварвания на Kubernetes (pods), защото в този случай няма начин да се проследи изходящата връзка от pod.
• NAT не работи правилно с непроследени пакети (тъй като ядрото съхранява NAT картографирането в conntrack).
• При преминаване през правилото „разреши всички“ в политиката за непроследени, всички пакети ще бъдат маркирани като непроследени. Това почти винаги не е това, което искате, така че е важно да сте много селективни по отношение на пакетите, разрешени от непроследените политики (и да позволите на повечето трафик да премине през нормални проследявани политики).
• Непроследените политики се прилагат в самото начало на тръбопровода за обработка на пакети. Това е много важно да се разбере, когато се създават политики на Calico. Можете да имате политика на под с поръчка:1 и непроследена политика с поръчка:1000. Няма значение. Политиката за непроследени ще бъде приложена преди политиката за групата. Непроследените политики зачитат реда на изпълнение само помежду си.

Тъй като една от целите на политиката doNotTrack е да наложи политиката много рано в тръбопровода за обработка на пакети на Linux, Calico прави задължително указването на опцията applyOnForward, когато използвате doNotTrack. Позовавайки се на диаграмата за обработка на пакети, имайте предвид, че политиката за непроследено(5) се прилага преди всякакви решения за маршрутизиране. Трафикът може да бъде насочен към хост процеса или може да бъде препратен към pod или друг възел.

Резултати от

Разгледахме различните опции на правилата (крайна точка на хост, ApplyOnForward, preDNAT и Untracked) в Calico и как се прилагат по пътя за обработка на пакети. Разбирането как работят те помага за разработването на ефективни и безопасни политики. С Calico можете да използвате глобална мрежова политика, която се прилага към етикет (група от възли и подове) и да прилагате политики с различни параметри. Това позволява на професионалистите по сигурността и мрежовия дизайн удобно да защитават „всичко“ (типове крайни точки) наведнъж, като използват единен език на политика с политики на Calico.

Признание: Бих искал да благодаря Шон Крамптън и Алекса Полита за техния преглед и ценна информация.

Източник: www.habr.com