Чому контейнери не повинні запускатися від імені root за замовчуванням?

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

Що насправді означає «запуск від імені root»

За замовчуванням багато образів контейнерів (особливо мінімальні або застарілі) виконують свій основний процес як UID 0 всередині контейнера. Оскільки контейнери спільно використовують ядро хоста з іншими контейнерами та самим хостом, root всередину контейнера — це не те саме, що root на повністю ізольованій віртуальній машині — але це все ще набагато потужніше, ніж мало б бути. Якщо зловмисник досягне виконання коду всередину контейнера, запущеного від імені root, він отримує:

• Повний доступ на читання/запис до будь-яких файлів, змонтованих у контейнер, незалежно від передбачених дозволів
• Можливість встановлювати пакети, змінювати бінарні файли або вносити зміни в стан програми
• Набагато простіший шлях до виходу з контейнера, якщо існує експлуатаційна вразливість ядра чи runtime
• Підвищену важель при комбінуванні з неправильно налаштованими томами, як-от змонтований Docker socket або шлях файлової системи хоста

Навіть без експлуатації ядра, доступ root всередину контейнера різко збільшує радіус ураження будь-якої вразливості рівня програми (SSRF, помилки десеріалізації, довільне написання файлів тощо).

Чому це більш важливо в оркестрованих середовищах

У кластерах Kubernetes контейнер, запущений від імені root, у поєднанні з надмірними можливостями Linux чи дозвільним контекстом безпеки дозволяє зловмиснику:

• Змінювати /proc чи /sys способами, які впливають на хост
• Підвищувати привілеї, якщо ввімкнені hostPID, hostNetwork чи hostIPC
• Зловживати змонтованим токеном облікового запису служби для бічного руху по кластеру
• Утекти на вузол, якщо встановлено privileged: true або надані небезпечні можливості на кшталт SYS_ADMIN

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

Практичні кроки гартування

1. Встановити користувача, який не є root, в образі

Явно визначте користувача, який не є root, у Dockerfile замість того, щоб покладатися на значення за замовчуванням:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Забезпечити на рівні оркестратора

Не покладайтесь лише на образ — забезпечте політику під час виконання. У Kubernetes використовуйте securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true змушує pod не пройти прийняття, якщо образ намагається запуститися як UID 0, даючи вам твердої гарантії замість умовної домовленості.

3. Відпустити непотрібні можливості

Більшість програм не потребують жодних з типових можливостей Linux, наданих контейнерам. Відпустіть усе й додайте назад лише те, що суворо необхідно (рідкі випадки, як-от прив'язка до низькопортів, можуть потребувати NET_BIND_SERVICE).

4. Уникати привілейованого режиму та спільного простору імен хоста

privileged: true, hostNetwork: true та hostPID: true повинні бути зарезервовані для дуже специфічних завантажень інфраструктури (як-от деякі агенти CNI чи моніторингу) — ніколи для загальних контейнерів програми.

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

Використовуйте контролери допуску чи механізми політики (наприклад, Kyverno, OPA/Gatekeeper) для автоматичного відхилення розгортань, які порушують ці правила, замість того, щоб покладатися на ручний перегляд коду. Поєднайте це зі скануванням образів у CI для виявлення образів із root користувачем до того, як вони потраплять у кластер.

Багатошарова, а не ідеальна, оборона

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

Хочете глибше зануритися в гартування хмарних навантажень? Дослідіть відповідні розділи Korra Studio з Cloud security та DevOps pipeline hardening, щоб доповнити решту вашої стратегії оборони в глибину.