Network Security Policies: чому трафік між сервісами відкритий
За замовчуванням мережа всередині кластера пласка: поди бачать одне одного напряму, а маршрут між вузлами не потребує підтвердження.
Поки Network Security Policies не задані, будь-який сервіс може звернутися до бази, брокера черг або внутрішнього API — не тому що так задумано, а тому що ніщо цього не забороняє.
Ціна такої картини видна при першому ж збої: помилка конфігурації або компроміс в одному сервісі відкриває доступ до сусідніх, а через той самий відкритий трафік між сервісами — до зовнішніх систем і сховищ. Розбираємо, як це закривається.
Сегментація навантаження будується на трьох питаннях: хто ініціює з'єднання, куди і на якому порту. Правило описують селекторами міток подів і просторів імен, тому ізоляція трафіку в кластері не прив'язана до адрес і не ламається при перестворенні подів.
Режим «заборонено все, крім дозволеного» вмикають першим, а винятки додають точково — за фактичними зв'язками, а не за припущеннями.
Порядок роботи зворотний звичному: спочатку знімаємо карту потоків за журналами та метриками мережі, відзначаємо обов'язкові зв'язки та налагоджувальні маршрути, що залишилися після запуску.
Потім описуємо політики безпеки мережі в Calico або Cilium, включаючи правила на вихідний трафік і дозвіл імен, і перевіряємо їх у тестовому контурі.
На виході — набір правил у репозиторії поруч із маніфестами: зміна проходить перевірку та розкатку так само, як код, а не руками в панелі.
Ізоляція трафіку між середовищами: класи відмов і час реакції
Сегментація починається з режиму заборони за замовчуванням (default-deny): у кожному просторі імен вхідний і вихідний трафік закрито, далі відкриваються лише потрібні пари «сервіс — сервіс» і порти.
Правила описують не «кому можна», а «кому не можна інакше» — зв'язки видно з маніфестів, а не реконструюються за журналами. Підхід підтримують поширені мережеві доповнення, включно з Calico, і переноситься між ними майже без переписування правил.
Які класи відмов перестають поширюватися: витік облікових даних у тестовому просторі імен більше не дає доступу до бойової бази, а заражений под не сканує сусідів — бічне переміщення обривається на першій забороні.
Помилка конфігурації, через яку сервіс лізе в чуже сховище, перехоплюється мережею, а не з'ясовується за зіпсованими даними.
Час розбору інциденту падає, бо політика — це виконувана схема зв'язків. Черговий бачить дозволені потоки й відсікає половину гіпотез одразу, а спрацьована заборона пишеться окремою подією — ланцюжок «хто до кого ходив» не потрібно збирати по крихтах.
Простій стає передбачуваним: радіус ураження обмежений одним сегментом, відкат — це повернення попередньої версії правил, а не відновлення всієї мережі. Нові правила спочатку застосовуються в режимі спостереження і лише потім блокують трафік.
Network Security Policies: режими контролю та обмеження
Штатно зв'язки всередині кластера відкриті: будь-яке робоче навантаження може звернутися до будь-якого. Мережеві політики перетворюють це на модель «дозволено лише перелічене» — правила описують, яким сервісам і на які порти можна ходити, і спираються на мітки, а не на адреси.
Виконує їх мережевий компонент кластера: якщо вибрана реалізація не підтримує потрібний набір полів, політика залишається описом без наслідків, а хибне відчуття захищеності дорожче за відсутність правил.
Чотири рівні ізоляції
Шари контролю вирішують різні завдання і на практиці поєднуються — вибір залежить від того, що саме потрібно закрити.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Штатні правила кластера | Однорідний кластер, зв'язки між сервісами передбачувані | Не керують трафіком за межі кластера; всередині дозволеної групи не розрізняють, хто саме звернувся |
| Правила на рівні вузлів | Потрібно закрити зв'язки між вузлами та вихід назовні, частина навантаження живе поза кластером | Задаються окремо від опису сервісів і розсинхронізуються при перенесеннях; налагодження дорожче |
| Ізоляція на зовнішньому периметрі | Кластер цілком у закритому сегменті, кілька середовищ під загальним контролем | Усередині сегмента зв'язки залишаються відкритими; контролю за окремими сервісами немає |
| Взаємна перевірка справжності | Важливо не лише «можна», а й «хто саме» звертається | Потрібні випуск і ротація посвідчень; вищі вимоги до супроводу |
Порядок впровадження зазвичай такий: вмикаємо штатні політики в режимі спостереження, збираємо за журналами реальні зв'язки, переводимо спостереження в блокування і лише потім додаємо вузлові правила та взаємну перевірку там, де потрібен захист від переміщення мережею.
Порядок впровадження: від інвентаризації трафіку до передачі
Порядок робіт будуємо так, щоб жоден бойовий сервіс не втратив зв'язність.
Спочатку знімаємо карту фактичних потоків, потім описуємо дозволені зв'язки і лише після цього вмикаємо блокування — у тестовому контурі, потім хвилями за просторами імен, із планом відкату на кожному кроці.
- Інвентаризація трафіку. Збираємо журнали мережевих потоків, запити DNS і метрики сервісної сітки за період, який покриває і регулярні завдання, і нічні регламенти. На виході — матриця «сервіс → сервіс → порт».
- Схема дозволених зв'язків. Залишаємо підтверджені зв'язки, спірні узгоджуємо з власниками сервісів. Базова лінія — заборона всього, що не описано явно.
- Налаштування в тестовому контурі. Переносимо політики на копію кластера і вмикаємо в режимі логування: правила рахуються, трафік не ріжеться. Так набираємо спрацьовування на реальному профілі навантаження без ризику.
- Перевірка політик. Проганяємо легітимні ланцюжки та наскрізні шляхи моніторингу, збирачів журналів і реєстру образів: дозволене проходить, зайве фіксується у звіті.
- Поетапне вмикання правил. Переводимо простори імен у блокуючий режим по одному, починаючи з некритичних контурів. Перед кожним кроком — контроль метрик доступності.
- Розбір блокувань. За журналами відділяємо шкідливий трафік від незадокументованого, але потрібного зв'язку: або точний виняток, або виправлення самого сервісу.
- Передача команді. Віддаємо політики в системі контролю версій, регламент змін, схему зв'язків та інструкцію черговому. Відкат — перемикання на попередній набір правил.
Маніфести, схеми потоків і регламент змін
Політика без опису живе рівно до першої зміни відповідального: новий інженер бачить набір правил і не розуміє, які зв'язки справді потрібні, а які залишилися від попередньої архітектури.
Тому разом із робочим контуром передаємо комплект, за яким правку можна внести усвідомлено, не відкриваючи зайвого.
- Реєстр дозволених потоків — хто з ким спілкується, на якому порту і який сервіс відповідає за зв'язок. На нього посилаються при розборі збою та при виведенні сервісу з експлуатації.
- Готові конфігурації політик — маніфести з зрозумілими іменами, розбиті за просторами імен, із помітками, які правила обов'язкові, а які тимчасові. Викочуються як є.
- Схема довіри — карта сегментів і напрямків трафіку: що вважаємо зовнішнім периметром, що внутрішньою зоною, де допускається звернення між середовищами та середовищами розробки.
- Регламент змін — порядок правки: заявка з обґрунтуванням, перевірка в тестовому контурі, вікно викочування, відповідальний за узгодження. Без нього правила швидко перетворюються на звалище винятків.
- Журнал блокувань і порядок розбору — куди дивитися при відмові сервісу, як відрізнити хибне спрацьовування від реальної спроби зв'язку і за який час правило знімається.
- Інструкція з відкату — як повернути попередній набір правил однією операцією, якщо після зміни посипалися залежності.
- Приймальні сценарії — перелік зв'язків, які перевіряються після кожної правки, щоб регрес ловився до робочого контуру.
Комплект ведеться в репозиторії разом із маніфестами, тому документація не розходиться з фактичним станом кластера: зміна політики та зміна її опису йдуть однією узгодженою дією.
Кейс: сегментація кластера без простою сервісів
До: пласка мережа
Кластер обслуговував продуктив, передпродукт і тестовий контур в одній мережі — будь-який под міг звернутися до будь-якого сервісу на будь-який порт.
Дозволеними були майже всі зв'язки: саме середовище не обмежувало нічого, а розбір інциденту починався з ручного перебору журналів по всіх вузлах і займав від чотирьох годин. Тестовий контур при цьому бачив бойові бази.
Що змінили
Спочатку зняли трафік за кілька циклів релізів і побудували граф залежностей «сервіс → сервіс → порт» — він і став джерелом правил.
Політики описували в Calico: спершу в режимі логування, коли зв'язки лише фіксуються, але не блокуються, потім увімкнули заборону за замовчуванням і точкові дозволи.
Кожному середовищу дали власний набір правил, тому передпродукт і тестовий контур перестали маршрутизуватися в продуктив.
Результат
Частка дозволених зв'язків скоротилася зі 100% до 11% — решта закрита явними заборонами. Розбір інциденту прискорився в рази: замість обходу вузлів достатньо подивитися журнал відхилених з'єднань, 30–40 хвилин замість половини робочого дня.
Правила вмикали без зупинки навантаження: черговий контролював потік відмов, відкат до попереднього профілю займав хвилини, вікна простою не знадобилося.
Чим мережеві політики відрізняються від ролей доступу?
Ролі доступу та мережеві політики закривають різні питання, і плутанина між ними залишає діри в захисті. Ролі розмежовують права: який обліковий запис може читати, створювати та змінювати об'єкти в системі управління.
Політики на рівні мережі відповідають на інше питання — які з'єднання між навантаженнями взагалі можливі.
Модель доступу будується навколо суб'єкта та дії: дозвіл видається на операцію з об'єктом. Мережа описується інакше — потоком: джерело, призначення, порт. Тому роль не зупинить уже запущений под, який звертається до чужої бази.
Різниця видна на прикладі. Обліковому запису сервісу дозволено читати секрети у своєму просторі імен — роль це дозволяє, і це нормально.
Але це не означає, що той самий сервіс повинен ходити в базу білінгу: політика забороняє з'єднання, і при компрометації поду зловмисник не потрапить у чужий контур.
За замовчуванням у кластері без політик трафік між просторами імен відкритий. Тому впровадження починають із заборони за замовчуванням і явних дозволів за селекторами подів: лише потрібні пари «сервіс → сервіс» і вихідний доступ до DNS.
Calico і Cilium застосовують такі правила на мережевому рівні та відкидають з'єднання до того, як воно дійде до застосунку.
Порівняння механізмів зводиться до зони відповідальності: ролі відповідають за управління кластером та його об'єктами, політики — за зв'язки між навантаженнями. Аудит теж різний: зміни прав видно в журналі системи управління, відхилені з'єднання — у лічильниках вузла. Модель доступу працює, лише коли налаштовано обидва шари.
Технічні сумніви: сумісність, відкати, підтримка
Політики мережевої безпеки змінюють те, як ходить трафік усередині кластера, тому сумніви в команд майже завжди однакові. Відповідаємо на ті, що задають найчастіше до старту.
Як зрозуміти, що політики не відріжуть робочий обмін?
Знімаємо картину поточних потоків: які сервіси та простори імен спілкуються, на яких портах, хто ходить назовні. Політики вмикаємо в режимі спостереження — вони лише логують, що було б відкинуто. Розібравши розбіжності, додаємо дозволи і лише потім переводимо правила в режим примусу.
Що буде з правилами, які вже є в кластері?
Інвентаризуємо все, що описано маніфестами, і зводимо в єдиний набір із перевіркою пріоритетів: при перетині результат вирішує порядок застосування. Контролери рахують цей порядок по-різному, тому два в одному кластері не змішуємо — залишається один.
Як відкотити зміни, якщо доступ зник?
Правила живуть декларативно в репозиторії, тому відкат — це повернення попередньої версії та її застосування, без ручних правок. Тримаємо принцип: «заборонити все» не застосовуємо першим кроком — дозволи для службового трафіку залишаються на місці до перемикання.
Хто супроводжує політики після передачі?
Віддаємо репозиторій із правилами, схему потоків між сервісами та інструкцію з діагностики: за якими журналами видно, що саме відкинуто. Перший час залишаємося на зв'язку і правимо правила разом із вашою командою, поки вона не вийде на самостійний режим.
Старт робіт: що потрібно з вашого боку та терміни
Порядок старту однаковий і для одного кластера, і для парку з десятків: спочатку вхідні дані, потім оцінка робіт, далі узгоджений план впровадження з термінами.
Без схеми середовищ і переліку сервісів оцінка перетворюється на вилку, а Network Security Policies доводиться перепроєктувати по ходу — тому збір даних виносимо на перший крок і фіксуємо результат письмово.
- Схема середовищ: кластери проду, передпродуктивного контуру та розробки, їхні зв'язки між собою та із зовнішніми мережами.
- Перелік сервісів: хто з ким спілкується, які зовнішні адреси та порти потрібні, де трафік іде в обидва боки.
- Точки входу: балансувальники, шлюзи, публікація сервісів, доступи до DNS і реєстру образів.
- Облікові дані: окрема роль із правом читати політики та увімкнений режим аудиту в тестовому контурі.
- Цільові вимоги: що саме обмежуємо — зв'язки між просторами імен, вихід в інтернет, доступ до баз даних.
- Обмеження: вікна, в які допустимі зміни в проді, та сервіси, які не можна зупиняти.
- Відповідальний з вашого боку: інженер, який підтверджує зв'язки та приймає результат.
Далі повертаємося з оцінкою за етапами та планом: пілот у тестовому контурі в режимі аудиту, коли політики лише логують трафік і нічого не блокують, звірка журналу з реальними зв'язками, переведення в режим блокування по одному простору імен, потім прод.
Від обговорення задачі до пілоту проходять дні, до повного переведення — тижні; точний термін залежить від кількості сервісів і зв'язків між ними.
