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

Мрежовият плъгин Calico предлага широк набор от мрежови политики с унифицирана синтаксис за защита на хостове на хардуер, виртуални машини и pod’ове. Тези политики могат да бъдат приложени в рамките на namespace или да бъдат глобални мрежови политики, приложими към host endpoint (за защита на приложения, работещи директно на хоста — хостът може да бъде директно сървър или виртуална машина) или към workload endpoint (за защита на приложения, работещи в контейнери или виртуални машини, разположени на хоста). Политиките Calico позволяват прилагането на мерки за сигурност за различни точки на мрежовия трафик чрез параметри като preDNAT, unraracked и applyOnForward. Разбирането на начина, по който тези опции работят, може да помогне за повишаване на сигурността и производителността на системата като цяло. В тази статия се обясняват основите на тези параметри на политиките Calico (preDNAT, unraracked и applyOnForward), приложими към host endpoints, с акцент върху това, какво се случва в пътищата за обработка на пакети (цепочки iptables).

Тази статия предполага, че имате разбиране за основните принципи на работа на мрежовите политики в Kubernetes и Calico. Ако не, препоръчваме да опитате basic network policy tutorial и host protection tutorial с Calico преди да прочетете тази статия. Също така разчитаме, че имате основно разбиране за работата на iptables в Linux.

Calico global network policy ви позволява да прилагате набор от правила за достъп по етикети (към групи хостове и workloads/pods). Това е много полезно, ако използвате различни системи — виртуални машини, система на хардуер или инфраструктура Kubernetes. Освен това, можете да защитите вашия клъстер (нодове) с набор от декларативни политики и да прилагате мрежови политики към входящия трафик (например, през NodePorts или външни IP адреси).

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

На Kubernetes възел, на който е стартиран Calico, можете да свържете виртуалния интерфейс (veth) с workload по следния начин. В примера по-долу можете да видите, че veth#10 (calic1cbf1ca0f8) е свързан с cnx-manager-* в calico-monitoring namespace.

[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 създава veth интерфейс за всяко workload, как прилага политиките? За това Calico създава хукове в различни вериги за обработка на пакети, използвайки iptables.

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

Обърнете внимание, че pod-ът също е външен обект (свързан с veth) от гледна точка на обработката на iptables. Да обобщим:

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

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

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

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

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

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

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

Крайни точки на хост

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

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

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

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

Обърнете внимание, че ако трябва да приложите една и съща мрежова политика както за хост-процеси, така и за pod-ове, не е необходимо да използвате опцията ApplyOnForward. Достатъчно е да създадете етикет за нужните hostendpoint и workload endpoint (pod). Calico е достатъчно умен, за да прилага политиката на базата на етикети, независимо от типа endpoint (hostendpoint или workload).

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

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

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

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

Untracked политика (5)

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

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

Когато зададете опцията "doNotTrack: true" в глобалната политика на мрежата Calico, тя става **неотслеживаема** политика и се прилага на най-ранния етап от обработката на пакетите в Linux. Ако погледнете схемата по-горе, политиките untracked се прилагат в веригите PREROUTING и OUTPUT в таблицата raw, преди да бъде стартирано проследяването на свързванията (conntrack). Когато пакетът бъде позволен от untracked политиката, той се маркира, за да се деактивира проследяването на свързването за този пакет. Това означава:

• Политиката untracked се прилага за всеки пакет. Няма понятие за свързване (или поток). Липсата на свързвания (connection) води до няколко важни последствия:
• Ако искате да разрешите както трафик на заявки, така и трафик на отговори, трябва да имате правило както за входящия, така и за изходящия (тъй като Calico обикновено използва conntrack, за да обозначи отговорния трафик като разрешен).
• Политиката untracked не работи за Kubernetes workloads (pod’ове), тъй като в този случай няма начин да се проследи изходящото свързване от pod’а.
• NAT не работи правилно с неотслеживаеми пакети (тъй като ядрото съхранява съвпадението NAT в conntrack).
• Когато преминете през правило "разреши всичко" в untracked-политиката, всички пакети ще бъдат маркирани като неотслеживаеми. Това почти винаги не е това, от което се нуждаете, затова е важно да бъдете много избирателни към пакетите, разрешени от untracked-политики (и да позволите на по-голямата част от трафика да преминава през обикновените политики с проследяване).
• Untracked-политиките се прилагат в самото начало на конвейера за обработка на пакети. Важно е да разберете това при създаването на политиките на Calico. Можете да имате политика за pod с order:1 и untracked-политика с order:1000. Това няма да има значение. Untracked-политиката ще бъде приложена преди политиката за pod. Untracked-политиките спазват реда на изпълнение само помежду си.

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

Резюме

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

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

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