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

Мрежовият плъгин Calico предлага широк набор от мрежови политики с унифициран синтаксис за защита на хостове на хардуер, виртуални машини и подове. Тези политики могат да се прилагат в рамките на пространство от имена или да бъдат глобални мрежови политики, приложими към 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-* в namespace 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
...

Като се има предвид, че 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, за да предостави възможност за прилагане на политики към целия трафик, преминаващ през хост точката, включително трафика, който ще бъде препратен от хоста (forwarded). Този трафик включва трафика, изпратен до локален 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 globalNetworkPolicy, тя става **неотслеживаема** политика и се прилага на най-ранния етап от обработката на пакетите в Linux. Ако погледнем диаграмата по-горе, политиките untracked се прилагат в веригите PREROUTING и OUTPUT в таблицата raw, преди да се стартира отслежването на връзките (conntrack). Когато един пакет бъде разрешен от untracked политиката, той се маркира, за да се деактивира отслежването на връзката за този пакет. Това означава:

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

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

Итог

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

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

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