Автоматизація безпеки Kubernetes: Kubesec і Kube-bench

Kubesec: що знаходить розбір маніфестів до викладки в кластер

Kubesec — статичний розбір конфігурації Kubernetes: описи перевіряються до викладки в кластер, а не після інциденту.

Інструмент читає маніфест так само, як це зробить API-сервер, і повертає оцінку ризику із зазначенням конкретного поля — від privileged: true до hostPath на корінь ноди.

Зайві права контейнера у дифі майже не видно: рядок securityContext або додана capability виглядають як звичайне налаштування.

На практиці такий под стає точкою входу на ноду — через змонтований сокет середовища виконання або кореневу файлову систему, далі по ланцюжку йдуть токен сервісного акаунта та API-сервер.

Не менш дороге — відсутність обмежень.

Без requests і limits один витік пам'яті витісняє сусідні робочі навантаження; без readOnlyRootFilesystem завантажений у контейнер код переживає перезапуск; automountServiceAccountToken за замовчуванням підставляє токен туди, де він не потрібен.

Рев'ю це пропускає зі зрозумілої причини: маніфести надходять із чартів, генераторів і копіпасти, зміни йдуть пачками, а перевірка тримається на увазі одного інженера.

Наші інженери описують це так: «набір дефектів повторюється від релізу до релізу — змінюються лише назви сервісів».

Перевірка маніфестів Kubernetes знімає саме повторюваність: у кожного опису з'являється числовий поріг і код повернення, тому правило вбудовується в складальний ланцюжок і зупиняє викладку до того, як под потрапить у кластер. Розбираємо, як це налаштовується під ваш процес і які пороги має сенс зафіксувати.

Що дає автоматична перевірка безпеки кластера

Автоматична перевірка безпеки переносить контроль вліво: опис контейнера оцінюється до потрапляння в кластер. Маніфести перевіряє Kubesec, налаштування вузлів і керуючого шару звіряються з еталонними профілями через kube-bench. Обидві перевірки вбудовуються в конвеєр складання і блокують викат при критичній знахідці.

Що саме перевіряється автоматично

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

Окремо перевіряється монтування каталогів вузла і доступ до сокету середовища виконання — частий шлях втечі з контейнера.

Другий шар — гігієна опису: задані ліміти й запити ресурсів, коренева файлова система лише для читання, прив'язка службового облікового запису, мережеві політики та правила доступу до секретів.

Як це позначається на релізах

Частка викатів, що доходять до кластера без зауважень щодо конфігурації, зростає до 9 з 10: критичні знахідки ловляться на рев'ю описів, а не в проді. Сам розбір прискорюється — інженер дивиться на звіт із пріоритетами, а не читає маніфест рядок за рядком.

Зникає клас відмов через зайві права: контейнер, що читає чужі секрети або монтує каталог вузла, просто не доїжджає до середовища.

Зниження кількості інцидентів видно й за швидкістю розбору: звіт прив'язаний до зміни конфігурації, тому причина відкату знаходиться за хвилини, а не за години пошуку по логах.

Підходи до перевірки: Kubesec, еталонна звірка, допуск політик

Підходи до перевірки відрізняються не суворістю, а точкою спрацювання: розбір маніфесту до застосування, аудит живого вузла, допуск на вході в кластер. Від цього залежить, чи ловить інструмент помилку до викату, чи фіксує її вже в працюючому середовищі.

Статичний розбір описів

Kubesec читає YAML-опис поду і оцінює поля, з яких складається ризик: привілейований режим, хостові каталоги, відсутність readonly-rootfs, зайві capabilities.

Поріг у конвеєрі складання відсікає такий маніфест до застосування, але перевірка бачить лише сам файл — значення за замовчуванням від API-сервера і фактичний стан вузлів залишаються поза нею.

Звірка з еталонними вимогами

kube-bench виконує перевірки за еталоном CIS окремо за компонентами — API-сервер, kubelet, etcd — і показує розбіжності з базовим профілем.

Це аудит за фактом: він не заважає зміні, а фіксує, що налаштування розійшлися з еталоном, і частина перевірок потребує доступу до файлів і процесів вузла.

Розбір описів дає швидкий зворотний зв'язок авторові, допуск політик закриває вхід у кластер, еталонна звірка ловить дрейф налаштувань, чек-ліст залишається для неформалізованого.

Як влаштований процес впровадження перевірок у кластер

Впровадження перевірок у кластер — це послідовність робіт, де сканер підключається останнім. Спочатку потрібно зрозуміти, що вже розгорнуто і які правила взагалі застосовні, інакше звіт дає сотні зауважень, половина яких — шум. Нижче — етапи налаштування, які ми проходимо в цьому порядку.

Підготовка: інвентаризація та схема

1. Інвентаризація кластера: збираємо всі описи ресурсів — маніфести з репозиторію, чарти, об'єкти, створені вручну. Фіксуємо, де джерело правди і де накопичилися розбіжності між репозиторієм і живим кластером.
2. Схема правил: визначаємо рівень контролю — лише попередження чи блокування зміни, — пріоритети перевірок і винятки для системних просторів імен. Kubesec розбирає описи статично, тому правила формулюємо незалежно від того, що відбувається в працюючому кластері.

Перевірка на реальних релізах

• Перевірка на історичних релізах: проганяємо правила на минулих версіях описів. Так видно, що зламається під час відкату або повторного застосування, — без цього кроку перевірки ловлять лише нові зміни.
• Розбір хибних спрацювань: кожне спірне правило обговорюємо з командою і фіксуємо винятки в конфігурації. Мета — не нуль зауважень, а нуль зауважень, які ніхто не збирається виправляти.
• Вбудовування в конвеєр: перевірки запускаються під час складання і перед застосуванням змін, із зрозумілим кодом повернення і посиланням на конкретне місце в описі.
• Передача команді: документація щодо правил, порядок додавання винятків і розбір типових помилок — щоб перевірки працювали без нашої участі.

Що залишається у вашому контурі: політики, схеми, регламенти

Прогін перевірок закінчується звітом, але цінність з'являється пізніше: коли правила, доступи і порядок дій живуть у вашої команди як робочі артефакти. Нижче — що саме залишається в контурі після впровадження і як цим користуватися без підрядника.

Політики та правила допуску

• Профіль правил перевірки маніфестів: заборона на привілейовані контейнери, монтування каталогів вузла і запуск від суперкористувача — з порогами, за яких викатка зупиняється, а не отримує попередження.
• Правила допуску в кластер: які простори імен доступні командам, що не можна створювати напряму, які обмеження накладаються на образи й ліміти ресурсів.
• Схема ролей і прав: ролі, прив'язки, службові облікові записи — окремий мінімум для чергового і для складального конвеєра.
• Порядок тимчасових винятків: у кожного власник, причина і дата перегляду, інакше виняток перетворюється на постійне відхилення.
• Правила перевірки вузлів і керуючого шару: еталонні налаштування і перелік відхилень, які ви визнали допустимими свідомо.

Документація та регламент реагування

• Регламент перевірок: що проганяється, з якою періодичністю, хто дивиться звіт і в який термін закриває знахідку.
• Інструкція для чергової зміни: як читати знахідку, що блокує викатку, кому і коли ескалювати.
• Журнал прогонів і знахідок: дати, статуси, відповідальні — за ним видно динаміку, а не зріз за один день.
• Документація для команди: як додати правило, оновити профіль перевірок, підключити новий репозиторій.

Кейс: як змінилися релізи після впровадження перевірок

Продуктова команда з дюжиною сервісів тримала безпеку на ручному рев'ю: маніфести вичитувалися очима, вузли кластера змінювалися без формального приймання.

Терміни впровадження зайняли три тижні — від інвентаризації робочих навантажень до включення блокувальних правил в обов'язковий маршрут складання.

Що було до впровадження

Дефекти конфігурації знаходили пізно і на різних стадіях. Контейнери запускалися з надмірними правами, не задавалися ліміти ресурсів, усередину монтувалися каталоги хоста.

Кожен четвертий викат відкочували, рев'ю маніфесту займало 40–60 хвилин, на реліз припадало близько дев'яти зауважень від експлуатації.

Що змінилося після

У маршрут додали два незалежні кроки: статичний розбір маніфестів через Kubesec з порогом за балами і блокуванням критичних правил, і регулярну звірку конфігурації вузлів із галузевим профілем безпеки. Звіт указує конкретний рядок маніфесту і йде авторові зміни до злиття, а не після аварії.

Через два місяці частка дефектних викатів упала з 24% до 4%, кількість зауважень на реліз — з дев'яти до двох, час рев'ю скоротився до 10–15 хвилин. Відкати стали поодинокими, розбір конфігураційних інцидентів перестав вимагати окремої зустрічі.

«Перевірки перестали бути ритуалом: інженер бачить порушення і виправляє його до злиття, а не під час розбору наслідків», — керівник напряму експлуатації.

Чим відрізняється Kubesec від Kube-bench і коли потрібен кожен

Kubesec і Kube-bench закривають різні зони охоплення перевірок. Kubesec читає описи об'єктів — YAML або відрендерений Helm-шаблон — і оцінює те, що видно до викладки: привілейовані контейнери, hostPath, securityContext, відсутність лімітів ресурсів. На виході — оцінка ризику і перелік конкретних рядків, які її знижують.

Kube-bench іде з іншого боку: звіряє фактичні налаштування працюючих вузлів і керуючих компонентів із вимогами галузевого стандарту. Перевіряються параметри запуску, права на конфігураційні файли, налаштування kubelet, доступ до сховища стану. Запускається завданням у кластері або прямо на вузлі — тобто відображає реальність, а не задум.

Різниця інструментів не в суворості, а в точці контролю. Kubesec — це відмова на етапі складання: маніфест із привілейованим контейнером просто не пройде перевірку.

Kube-bench — звіт про стан середовища, за яким видно, що налаштування роз'їхалися після ручного втручання або оновлення вузла.

Вибір інструмента під задачу визначається тим, який клас відмов дорожчий. Не пустити ризик у кластер — починають із Kubesec. Підтвердити відповідність вимогам і зловити дрейф конфігурації — з Kube-bench.

На практиці обидва стоять в одному процесі: перший перевіряє те, що збираємося викласти, другий — те, що вже працює.

Сумніви щодо автоматичних перевірок: навантаження і хибні спрацювання

Автоматичні перевірки безпеки працюють у двох точках: розбір маніфестів до застосування і звірка конфігурації вузлів з еталонним профілем (Kubesec і kube-bench). Це різні контури з різною ціною помилки, тому включати їх одним кроком викату не варто.

На практиці впровадження впирається в чотири питання — від хибних спрацювань до того, хто доводить зауваження до виправлення.

Перевірки сповільнять процес викату?

Розбір маніфестів — це читання файлів без звернень до сервера керування, добавка до кроку вимірюється секундами. Звірка вузлів іде за розкладом, поза релізним вікном, і з викатом не перетинається.

Чи спрацює на вже розгорнутому кластері?

Так: агент ставиться на вузли, розбір підключається до конвеєра, перескладання сервісів не потрібне. Перший прохід дає інвентаризацію — скільки контейнерів із розширеними правами, хто пише в каталоги вузла, де немає лімітів. Профіль посилюється поетапно, за групами, щоб не зупинити робочі сервіси.

Хто виправляє знайдене?

Правила, шаблони і список винятків веде платформна команда, маніфести свого сервісу править його розробка. Зауваження перетворюються на задачі з пріоритетом за типом ризику, а повторні порушення відсікаються ще на розборі — до потрапляння в кластер.

Обговоримо задачу і повернемося з планом перевірок для кластера

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

Далі фіксуємо межі робіт і порядок співпраці: що робимо ми, де потрібні ваші інженери, у яких точках узгоджуємо зміни. Нижче — що уточнюємо на старті і що ви отримуєте після розмови.

• Уточнюємо поточний стан: де лежать маніфести, хто вносить зміни, чи є контроль на етапі складання образу.
• Розбираємо вимоги: внутрішні політики безпеки, галузеві норми, допустиме вікно правок у проді.
• Узгоджуємо план перевірок: Kubesec — маніфести й образи, kube-bench — налаштування вузлів і керуючого шару; що йде в обов'язковий набір, а що в режим спостереження.
• Даємо оцінку робіт за етапами: обсяг, послідовність, залежності — без прихованих пунктів.
• Описуємо порядок співпраці: доступи й ролі, регламент змін, точки узгодження, формат звітності.
• Прописуємо передачу результату: конфігурації перевірок у вашому репозиторії, вбудовані в конвеєр складання, документація з розбору знахідок.

Опишіть задачу — повернемося з оцінкою і планом перевірок для вашого кластера.