Розуміння варіантів застосування мережевих політик із Calico

Мережевий плагін Calico надає широкий набір мережевих політик із уніфікованим синтаксисом для захисту хостів на залізі, віртуальних машин та pod'ів. Ці політики можуть застосовуватися в рамках namespace або бути глобальними мережевими політиками, які застосовуються до host endpoint (для захисту додатків, що працюють безпосередньо на хості — хостом може бути безпосередньо сервер або віртуальна машина) або до workload endpoint (для захисту програм, що працюють у контейнерах або віртуальних машинах, розміщених на хості). Політики Calico дозволяють застосувати заходи безпеки для різних точок шляху пакетів за допомогою таких параметрів, як preDNAT, unraracked і applyOnForward. Розуміння того, як ці опції працюють, може допомогти підвищити безпеку та продуктивність системи загалом. У цій статті пояснюється суть даних параметрів політик Calico (preDNAT, unraracked і applyOnForward), що застосовуються до host endpoints, з акцентом на тому, що відбувається в шляхах обробки пакетів (ланцюжків iptabels).

Ця стаття передбачає, що у вас є розуміння базових принципів роботи мережевих політик Kubernetes та Calico. Якщо ні, то рекомендуємо спробувати basic network policy tutorial и host protection tutorial використовуючи Calico, перш ніж читати цю статтю. Ми також розраховуємо, що ви маєте базове розуміння роботи Iptables у Linux.

коленкор Global network policy дозволяє вам застосовувати набір правил доступу по labels (до груп хостів та workloads/pods). Це дуже корисно, якщо ви використовуєте разом різноманітні системи - віртуальні машини, систему безпосередньо на залізі або інфраструктуру kubernetes. До того ж, ви можете захистити свій кластер (ноди) за допомогою набору декларативних політик та застосовувати мережеві політики до вхідного трафіку (наприклад, через NodePorts або External IPs).

На фундаментальному рівні, коли Calico підключає pod до мережі (див. нижче), він підключає його до хоста за допомогою віртуального інтерфейсу Ethernet (veth). Відправлений pod'ом трафік приходить на хост з даного віртуального інтерфейсу і обробляється так само, якби він прийшов від фізичного мережевого інтерфейсу. За замовчуванням, Calico називає ці інтерфейси caliXXX. Оскільки трафік надходить через віртуальний інтерфейс, він проходить через iptables, ніби pod знаходився на відстані одного hop'a. Тому, коли трафік приходить/виходить від pod'a, він пересилається (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: <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-інтерфейс для кожного workload, як він застосовує політику? Для цього Calico створює хуки в різні ланцюжки шляху обробки пакетів, використовуючи iptables.

На діаграмі нижче показані ланцюжки, що беруть участь у обробці пакетів в iptables (або підсистемі netfilter). Коли пакет надходить через мережний інтерфейс, він спочатку проходить через ланцюжок PREROUTING. Потім приймається рішення про маршрутизації, і на підставі цього пакет проходить через INPUT (спрямований на процеси хоста), або через FORWARD (спрямований на pod або на іншу ноду в мережі). З локального процесу пакет проходить через ланцюжок OUTPUT, потім POSTROUTING перед відправкою по кабелю.

Зверніть увагу, що під також є зовнішнім об'єктом (підключеним до veth) з точки зору обробки iptables. Підведемо підсумки:

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

Calico надає опції для політик, за допомогою яких можна застосовувати політики для всіх ланцюжків. Маючи це на увазі, давайте розглянемо різні варіанти налаштування політик, доступних у Calico. Цифри у списку опцій нижче відповідають цифрам на діаграмі вище.

1. Workload endpoint (pod) policy
2. Host endpoint policy
3. Опція ApplyOnForward
4. Політика PreDNAT
5. Політика Untracked

Давайте почнемо з розгляду того, як політики застосовуються до workload endpoints (pod'ам Kubernetes або OpenStack VMs), а потім розглянемо опції політик для host endpoints.

Workload Endpoints

Workload Endpoint Policy (1)

Це опція для захисту ваших kubernetes pod'ів. У Calico підтримується робота з Kubernetes NetworkPolicy, але також надає додаткові політики — Calico NetworkPolicy і GlobalNetworkPolicy. Calico створює ланцюжок для кожного pod'а (workload) та хуки в ланцюжки INPUT та OUTPUT для workload до таблиці фільтрів ланцюжка FORWARD.

Host Endpoints

Host Endpoint Policy (2)

Крім CNI (container network interface), політики Calico надають можливість захисту безпосередньо хоста. У Calico ви можете створити host endpoint, задавши комбінацію з інтерфейсу хоста і, якщо потрібно, номерів портів. Застосування політик цієї сутності досягається з допомогою таблиці фільтрів в ланцюжках INPUT і OUTPUT. Як видно з діаграми (2), вони застосовуються до локальних процесів на ноді/хості. Тобто, якщо ви створили політику, яка застосовується до host endpoint, вона не вплине на трафік, що йде до/від ваших pod'ів. Але за рахунок неї забезпечується єдиний інтерфейс/синтаксис для блокування трафіку для вашого хоста та pod'ів за допомогою політик Calico. Це значно полегшує процес управління політиками для різнорідної мережі. Налаштування host endpoint політик для посилення захисту кластера – це ще один важливий випадок їхнього використання.

ApplyOnForward Policy (3)

Опція ApplyOnForward доступна в Calico Global Network Policy, щоб дати можливість застосування політик до всього трафіку, що проходить через host endpoint, включаючи трафік, який буде перенаправлятися хостом (forwarded). Цей трафік включає пересилається в локальний pod або кудись ще в мережу. Calico вимагає, щоб цей параметр був увімкнений для політик, що використовують PreDNAT і untracked, див. наступні розділи. Крім того, ApplyOnForward можна використовувати для відстеження трафіку хоста у разі використання віртуального роутера або програмного NAT.

Зауважте, що якщо вам потрібно застосувати ту саму мережну політику як для хост-процесів, так і для pod'ів, то вам не обов'язково використовувати опцію ApplyOnForward. Вам достатньо створити мітку для потрібних hostendpoint і workload endpoint (pod). Calico досить розумний, щоб застосовувати політику на основі labels, незалежно від типу endpoint (hostendpoint чи workload).

PreDNAT Policy (4)

У Kubernetes порти сутності service можуть бути прокинуті назовні за допомогою опції NodePorts або опціонально (при використанні Calico), за допомогою оголошення їх через опції Cluster IPs або External IPs. Kube-proxy балансує вхідний трафік, прив'язаний до service, до pod's відповідних service, використовуючи DNAT. Враховуючи це, як вам застосувати політики для трафіку через NodePorts? Щоб ці політики були застосовані до того, як трафік буде оброблений DNAT (який представляє собою зіставлення хоста: порту та відповідного service), Calico надає параметр для globalNetworkPolicy, який називається «preDNAT: true».

Коли pre-DNAT включений, ці політики реалізуються в (4) на діаграмі - таблиці mangle ланцюжка PREROUTING - безпосередньо перед DNAT. Звичайний порядок політик (order) тут не дотримується, оскільки застосування цих політик відбувається набагато раніше шляхом обробки трафіку. Тим не менш, політики preDNAT дотримуються порядку застосування між собою.

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

Untracked Policy (5)

Мережі та програми можуть мати великі відмінності у поведінці. У деяких крайніх випадках програми можуть генерувати безліч короткочасних з'єднань. Це може призвести до нестачі пам'яті у conntrack (основного компонента стека Linux). Традиційно для запуску програм такого типу в Linux вам потрібно вручну налаштувати або вимкнути conntrack, або написати правила iptables, щоб обійти conntrack. Untracked policy в Calico - це більш простий та ефективний варіант, якщо ви хочете обробляти з'єднання максимально швидко. Наприклад, якщо ви використовуєте масивний Memcache або як додатковий захід захисту від DDOS.

Читайте цей блог (або наш переклад) для отримання додаткової інформації, включаючи тести продуктивності при використанні untracked policy.

Коли ви задаєте опцію «doNotTrack: true» в Calico globalNetworkPolicy, вона стає **невідстежуваною** політикою і застосовується на ранньому етапі конвеєра обробки пакетів Linux. Якщо подивитися на діаграму вище, політики untracked застосовуються в ланцюжках PREROUTING і OUTPUT в таблиці raw, перш ніж буде запущено відстеження з'єднань (conntrack). Коли пакет дозволено untracked політикою, він позначається, щоб відключити відстеження з'єднання для цього пакета. Це означає:

• Політика untracked застосовується для кожного пакету. Немає поняття сполуки (чи потоку). Відсутність з'єднань (connection) спричиняє кілька важливих наслідків:
• Якщо ви хочете дозволити як трафік запиту, так і трафік відповіді, вам необхідно правило як для вхідного, так і для вихідного (оскільки Calico зазвичай використовує conntrack, щоб відзначити трафік у відповідь як дозволений).
• Політика untracked не працює для workload Kubernetes (pod'ов), тому що в даному випадку немає способу відстежити вихідне з'єднання з pod'а.
• NAT працює некоректно з пакетами, що не відслідковуються (оскільки ядро ​​зберігає зіставлення NAT в conntrack).
• При проходженні через правило «дозволити все» в untracked-політиці всі пакети будуть позначені як відслідковувані. Це майже завжди не те, що вам потрібно, тому важливо бути дуже вибірковим до пакетів дозволеним untracked-політиками (і дозволяти більшій частині трафіку проходити через звичайні політики, що відстежуються).
• Untracked політики застосовуються на самому початку конвеєра обробки пакетів. Це дуже важливо розуміти під час створення політик Calico. У вас може бути політика для pod'a з order:1 та untracked-політика з order:1000. Це буде неважливо. Untracked-політика буде застосована до політики для pod'a. Untracked-політики дотримуються черговості виконання лише між собою.

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

Підсумки

Ми розглянули різні опції політик (Host endpoint, ApplyOnForward, preDNAT, та Untracked) у Calico і як вони застосовуються на шляху обробки пакетів. Розуміння суті їхньої роботи допомагає у розробці ефективних та безпечних політик. За допомогою Calico ви можете використовувати global network policy, яка застосовується до label (групи нод та pod'ів) та застосовувати політики з різними параметрами. Це дозволяє фахівцям з безпеки та проектування мережі зручно захищати одразу все (типи endpoints), використовуючи єдину мову політик з політиками Calico.

Подяка: Я хотів би подякувати Шона Кремптона и Олекса Поллітта за їх огляд та за цінну інформацію.

Джерело: habr.com