Kubernetes безпека подів: впровадження Pod Security Standards

Pod Security Standards: чому поди отримують зайві права

Типова картина в кластері, якому більше року: у маніфестах стоїть privileged: true або hostNetwork: true, контейнер запущено від root, а hostPath монтує каталог вузла.

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

Чому таке не ловиться: за замовчуванням нічого не обмежує. API-сервер Kubernetes приймає будь-який securityContext, якщо в кластері не налаштовані контролери допуску, а право створювати поди в просторі імен надано майже кожному сервісному акаунту.

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

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

Запуск від root разом із монтуванням каталогу вузла або сокета середовища виконання відкриває шлях до сусідніх подів, а hostNetwork — до мережевих метаданих хмари. Уразливості середнього рівня перетворюються на критичні.

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

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

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

Після увімкнення Pod Security Standards у режимі обмеження такі контейнери не проходять створення, і частка привілейованих подів падає до нуля без ручного розбору кожного маніфесту.

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

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

Порівняння режимів Pod Security: baseline і restricted

У Pod Security Standards три рівні політик, і вибір між ними — це вибір класу навантаження, а не принцип «суворіше означає краще».

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

baseline закриває очевидно небезпечне: хостові мережеві простори та процеси, запуск від root, зайві capability. restricted додає вимоги до профілю seccomp, кореневої файлової системи лише для читання, запуску від непривілейованого користувача та явного скидання всіх capability.

Вмикати рівні одразу в примусовому режимі ризиковано: режим попередження повертає список порушень у відповіді API-сервера й пише їх у журнал аудиту, не блокуючи запуск.

Команда бачить реальний профіль навантаження, править маніфести й лише потім переводить простір імен у примусовий режим — спочатку на нових сервісах, потім на решті.

Як ми впроваджуємо політики: аудит, схема, перевірка, передача

Впровадження Pod Security Standards — це не одна мітка на простір імен. Політики розкривають те, що роками накопичувалося в маніфестах: привілейовані контейнери, hostPath, hostNetwork, запуск від root, зайві capabilities.

Тому йдемо від інвентаризації до м'якого режиму й лише потім до блокування, зі зворотним шляхом на кожному кроці.

1. Аудит кластера та інвентаризація маніфестів. Збираємо робочі навантаження за просторами імен, включно з CronJob, DaemonSet та операторами, і фіксуємо за кожним користувача, привілеї та монтування. Результат — таблиця «навантаження → порушувані правила», а не загальний потік попереджень.
2. Схема переведення. Розкладаємо навантаження за трьома профілями — обмежений, базовий, привілейований — і вирішуємо, які простори імен отримають блокувальний режим одразу, а які підуть через м'який.
3. Увімкнення в м'якому режимі. Проставляємо мітки аудиту та попереджень: контролер нічого не блокує, але кожне порушення потрапляє в події та лог. Кілька днів режиму показують реальний обсяг правок без ризику для бойового контуру.
4. Перевірка конфігурацій. Переписуємо маніфести під потрібний профіль: знімаємо зайві capabilities, прибираємо hostPath на користь томів, задаємо runAsNonRoot і seccomp. Правки проходять рев'ю та прогін у тестовому контурі.
5. Переведення навантаження. Блокування вмикаємо за просторами імен — від менш критичних до бойових, зі спостереженням за відмовами та швидким відкатом мітки.
6. Передача регламентів. Віддаємо політики як код у репозиторії, правила для нових сервісів, чек-ліст рев'ю маніфестів і порядок винятків.

Артефакти впровадження: політики доступу, ролі та регламенти

Команда замовника отримує не набір разових команд, а робочий комплект, за яким можна чергувати й змінювати політики без нас. Нижче — що саме залишається в репозиторії та у внутрішній базі знань після впровадження Pod Security Standards.

• Конфігурації кластера: маніфести просторів імен із мітками pod-security.kubernetes.io/enforce, audit і warn, вибрані рівні baseline або restricted, окремий перелік винятків для системних просторів імен.
• Матриця ролей: таблиця «простір імен — рівень політики — хто має право виводити навантаження з-під неї», з прив'язкою до ролей доступу та розділенням права змінювати політику і права на реліз.
• Схеми розміщення навантаження: які робочі навантаження живуть у строгому профілі, а де потрібні привілеї — із зазначенням причини та власника, а не позначкою «розберемося пізніше».
• Регламенти безпеки: порядок випуску політики — спочатку режими аудиту та попередження на живому трафіку, потім увімкнення примусового режиму за заздалегідь узгодженим критерієм за кількістю порушень у журналі.
• Інструкції для чергової зміни: що робити, коли под не створюється через політику — як читати повідомлення контролера допуску, де шукати виняток, як відкотити зміну, не знімаючи весь режим повністю.
• Документація для розробників: еталонний маніфест з обов'язковими полями — запуск не від суперкористувача, профіль seccomp, коренева файлова система лише для читання, скинуті можливості.

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

Кейс: як прибрали привілейовані поди без простою сервісів

Вихідна точка

Кластер на кілька десятків команд: 46 namespace, з них 11 із привілейованими подами — мережевий агент, збір логів, драйвери вузлів.

Аудит Kubernetes показував, що 88% контейнерів запускалися без профілю seccomp, а шість із десяти робочих навантажень мали allowPrivilegeEscalation: true.

Загальної політики не було: кожен namespace жив за своїми правилами, і будь-який сервіс міг отримати монтування каталогу вузла.

Порядок переведення

Почали з режимів warn і audit на всіх namespace — за тиждень зібрали звіт за порушеннями та розклали їх на три групи: правка маніфестів, заміна образів, системні винятки.

Далі вмикали enforce хвилями: спочатку stateless-сервіси, потім stateful-набори з постійними томами, останніми — агенти на кожному вузлі, які не можна перервати без втрати самого вузла.

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

Результат

Практичний підсумок через два релізних цикли: привілейованих подів у робочих namespace — нуль, частка контейнерів без seccomp упала з 88% до 4%. Відмов на етапі допуску під час викатки — нуль після перших двох тижнів, коли команди звикли до нових вимог.

Запуск від root і монтування каталогів вузла закриті, а новий сервіс за замовчуванням отримує профіль restricted і не потребує окремих погоджень із безпекою.

Що робити, якщо в кластері вже розгорнуті привілейовані поди?

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

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

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

Виняток описує конкретні правила — монтування каталогів хоста, підвищення привілеїв, додаткові можливості ядра — і прив'язується до одного простору імен. Кожен запис отримує причину, власника та дату перегляду.

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

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

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

Технічні сумніви інженерних команд: ризики та сумісність

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

Як бути із системними компонентами кластера?

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

Що найчастіше не проходить перевірку в застосунках?

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

Чи можливий відкат змін?

Так: рівень задається міткою на просторі імен, і зняття мітки повертає попередню поведінку за секунди, без перескладання кластера. Застереження — відкат не відновлює поди, відхилені примусом, тому переводимо простори імен по одному, зі спостереженням на кожному кроці.

Обговоримо задачу: підберемо режим і план переходу

Щоб підібрати режим Pod Security Standards і зібрати схему впровадження, достатньо вступного зрізу по кластеру: кількість просторів імен, уже проставлені мітки, наявність привілейованих робочих навантажень. Цього достатньо, щоб дати оцінку робіт за етапами, а не рахувати наосліп.

Що потрібно від вас:

• перелік просторів імен із власниками та порядком викатки;
• зріз поточних маніфестів або доступ до конфігурації лише для читання;
• список навантажень, яким потрібні привілеї, хостові порти або томи — з обґрунтуванням;
• вікно, коли можна увімкнути аудит і дивитися попередження без впливу на прод;
• контакт чергового інженера на час переведення та відомості про тестовий контур.

Що віддаємо натомість:

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

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