Безпека контейнерів Kubernetes: що ігнорують під час виконання

Прогалини в безпеці Kubernetes під час виконання

Розмови про безпеку Kubernetes часто зосереджуються на етапах, що передують виконанню, таких як сканування образів, посилення Dockerfiles та робота з контролем доступу до реєстру. Хоча це необхідно, такий підхід залишає значні прогалини, коли контейнеризовані робочі навантаження вже працюють у виробничому середовищі. Зростання впровадження контейнерів у багатьох секторах промисловості збільшує поверхню атаки. Наприклад, у листопаді 2025 року дослідник SUSE виявив три вразливості runC, які дозволяли зловмиснику вийти з контейнера та отримати root-доступ на хості. Це перетворило безпеку під час виконання контейнерів з гіпотетичної на практичну проблему, що має величезне значення для команд, які працюють з Kubernetes.

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

Безпека під час виконання (runtime security) охоплює інструменти, політики та практики для моніторингу та захисту контейнерів під час їх роботи у виробництві. Вона є критично важливою. Необхідно мати можливість ідентифікувати проблеми, пов'язані з виконанням процесів, активністю файлової системи, мережевою поведінкою та системними викликами в реальному часі. Моніторинг під час виконання повинен відстежувати:

Несподівані бінарні файли
Скрипти, що запускаються всередині контейнерів
Записи до шляхів, доступних лише для читання
Вихідні та бічні комунікації
Системні виклики

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

Поширені прогалини під час виконання

Існує кілька поширених недоліків, які команди часто ігнорують:

Запуск контейнерів від імені Root

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

Для вирішення цієї проблеми є важливими явні оголошення runAsUser та runsAsNonRoot. Зменшення кількості бінарних файлів за допомогою distroless або мінімальних базових образів також має велике значення. Стандарти безпеки Pod у Kubernetes також повинні обмежувати профілі та забезпечувати роботу без root-прав.

Надмірно дозвольні RBAC та мережеві політики

Контроль доступу на основі ролей (RBAC) добре служить як система дозволів за замовчуванням у багатьох налаштуваннях безпеки Kubernetes. Однак дозвольні тенденції призводять до того, що поди спілкуються з усіма іншими подами "з коробки". Команди часто додають кластерного адміністратора або широкі ролі, що ще більше погіршує проблему, хоча й спрощує налагодження. Сторони часто не переглядають ці рішення пізніше.

Надмірно дозвольні дозволи RBAC можуть дозволити зловмисникам:

Перелічувати секрети
Створювати привілейовані поди
Отримувати доступ до API-сервера Kubernetes

Рішення полягає в тому, щоб за замовчуванням заборонити всі мережеві політики для кожного простору імен. Трафік повинен потрапляти до явного списку дозволених, щоб пройти. Деталізоване застосування має здійснюватися через плагіни CNI. Також необхідно регулярно перевіряти RBAC та візуалізувати дозволи.

Відсутність виявлення загроз у реальному часі

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

Зловмисники часто розгортають такі системи, як:

Майнери XMRig для споживання обчислювальних ресурсів кластера
Зворотні оболонки для постійного доступу
Пробники та експлойти нещодавно розкритих CVE у розгорнутих образах
Маніпулювання змонтованими секретами або токенами облікових записів служб

Розгортання виявлення під час виконання більше не підлягає обговоренню. Інструменти на рівні ядра з низькими накладними витратами мають велике значення. Потім можна відстежувати несподівані дочірні процеси, записи до критичних папок, таких як bin або etcd, виявляти вихідні з'єднання та відстежувати спроби підвищення привілеїв.

Ігнорування дрейфу конфігурації

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

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

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

Шар виконання як вектор атаки

Раніше обговорювані CVE 2025 року вказують на шар виконання як життєздатний вектор атаки. Зловмисники можуть використовувати символічні посилання для обходу bind-mounts, що захищають файли хоста. Перенаправлення монтування також може відбутися до того, як спрацюють очікувані засоби захисту. Ін'єкція процесів або несанкціонований доступ до пам'яті також можуть спричинити збої системи або підвищення привілеїв. Неправильно налаштовані конфігурації під час виконання можуть викрити файлову систему хоста та створити можливості для виходу з контейнера або підвищення привілеїв. Дормантні облікові дані в більшості систем Kubernetes надають додаткову приховану поверхню атаки. Зловмисники все частіше атакують шар виконання та точки входу ланцюга постачання, а не зосереджуються на вразливостях додатків та коду.

Практична позиція безпеки під час виконання

Стандарти безпеки Pod є обов'язковими. Обмеження профілів також є важливими. Можна блокувати привілейовані контейнери, простори імен хоста, root-користувачів та небезпечні типи томів.

Впровадьте моніторинг під час виконання якомога швидше. Необхідно мати можливість спостерігати за несподіваними запусками процесів, модифікаціями за межами шляхів файлової системи, доступних для запису, дивними мережевими з'єднаннями та системними викликами, що підвищують привілеїв. Найкращі інструменти пропонують низькі накладні витрати під час виконання, зазвичай споживаючи 1-2,5% потужності процесора.

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

Скануйте безперервно, а не лише під час збірки. Виявляйте та запобігайте дрейфу. Також переконайтеся, що ви ввімкнули та постійно моніторите журнали аудиту.

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

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

Що це означає для розробників

Розробникам слід усвідомити, що безпека не закінчується на етапі збірки. Необхідно активно використовувати runAsUser та runsAsNonRoot, мінімізувати бінарні файли в образах та враховувати вплив RBAC і мережевих політик на потенційні вектори атак під час виконання.

Ключові факти

Безпека Kubernetes часто зосереджується на етапах до виконання (сканування образів, Dockerfiles, контроль доступу до реєстру), залишаючи прогалини під час роботи контейнерів.
У листопаді 2025 року дослідник SUSE виявив три вразливості runC, що дозволяли зловмиснику вийти з контейнера та отримати root-доступ на хості.
Безпека під час виконання контейнерів (runtime security) передбачає моніторинг та захист контейнерів у реальному часі від несподіваних бінарних файлів, скриптів, записів у read-only шляхи, вихідних/бічних комунікацій та системних викликів.
Поширені прогалини включають запуск контейнерів від імені root, надмірно дозвольні RBAC та мережеві політики, відсутність виявлення загроз у реальному часі та ігнорування дрейфу конфігурації.
Для підвищення безпеки рекомендується використовувати runAsUser та runsAsNonRoot, обмежувати бінарні файли, застосовувати політики "заборонити за замовчуванням" для мережевого трафіку, впроваджувати інструменти виявлення загроз на рівні ядра та забезпечувати файлові системи root лише для читання.