Почему плохо запускать контейнер от root?

Почему контейнеры не следует запускать от пользователя root

Запуск контейнеров от пользователя root (пользователя с UID 0 внутри контейнера) — это распространённая, но опасная практика, которая создаёт серьёзные угрозы безопасности всей хост-системы. Хотя контейнеры обеспечивают некоторую степень изоляции через механизмы ядра Linux (namespaces, cgroups, Seccomp, AppArmor и др.), они не являются полноценными виртуальными машинами и напрямую используют ядро хоста. Это означает, что компрометация контейнера, запущенного от root, может привести к эскалации привилегий и компрометации всей хост-системы. Рассмотрим основные риски и причины, почему это плохо.

Ключевые риски безопасности

1. Эскалация привилегий через уязвимости ядра

   • Если контейнер работает от root, злоумышленник, получивший доступ к контейнеру (например, через эксплойт в приложении), может использовать уязвимости в реализации namespaces, cgroups или других компонентов ядра для выполнения произвольного кода на хосте с правами root.
   • Пример: уязвимости типа CVE-2022-0185 (ошибка в подсистеме filesystem context) позволяли выходить за пределы контейнера.

2. Монтирование чувствительных директорий хоста

   • При запуске контейнера от root, если администратор смонтировал в контейнер директорию хоста (например, через -v /:/host), процессы внутри контейнера получают полный доступ к файловой системе хоста, включая /etc, /root, /var/lib/docker.
   • Злоумышленник может модифицировать системные файлы, украсть секреты или установить backdoor.

3. Обход механизмов Mandatory Access Control (MAC)

   • Политики SELinux или AppArmor, часто применяемые для дополнительной защиты, могут быть ослаблены при запуске контейнера от root. Например, неправильно настроенный профиль AppArmor может разрешать операциям из контейнера доступ к ресурсам хоста.

4. Уязвимости в runtime (runc, containerd)

   • Известные уязвимости, такие как CVE-2019-5736 (runc), позволяли контейнеру с правами root перезаписать бинарный файл runc на хосте и выполнить код с максимальными привилегиями.

5. Неизолированные системные вызовы

   • Некоторые системные вызовы (например, связанные с модулями ядра, сетевым стеком) могут влиять на хост, даже если они вызваны из контейнера. Процесс root в контейнере имеет больше возможностей для таких вызовов.

Практические рекомендации и меры противодействия

Для минимизации рисков следует применять следующие подходы:

• Запуск контейнеров от непривилегированного пользователя (non-root user)

  • Создавайте пользователя с произвольным UID (например, 1000) внутри Dockerfile и запускайте приложение от его имени:

  FROM alpine:latest
  RUN addgroup -g 1000 appgroup && adduser -u 1000 -G appgroup -D appuser
  USER appuser
  CMD ["sh", "-c", "echo 'Running as non-root'"]
  

  • В Kubernetes можно задать securityContext в манифесте пода:

  apiVersion: v1
  kind: Pod
  metadata:
    name: nonroot-pod
  spec:
    securityContext:
      runAsUser: 1000
      runAsGroup: 1000
    containers:
    - name: app
      image: myapp:latest
  

• Использование механизмов безопасности ядра

  • Seccomp: применяйте ограниченные профили Seccomp (например, профиль по умолчанию в Docker) для фильтрации системных вызовов.
  • AppArmor/SELinux: настройте строгие профили для контейнеров.
  • No New Privileges: включайте опцию no-new-privileges: true в Docker или Kubernetes, чтобы запретить процессу повышать привилегии через setuid-бинарники.
  • Read-only корневая файловая система: монтируйте корень контейнера как read-only (readOnlyRootFilesystem: true в Kubernetes), чтобы предотвратить модификацию системных файлов.

• Ограничение возможностей Linux (Capabilities)

  • По умолчанию Docker запускает контейнеры с ограниченным набором capabilities, но для root-контейнеров некоторые опасные возможности (как CAP_SYS_ADMIN) всё равно могут присутствовать. Рекомендуется явно удалять все ненужные возможности и добавлять только минимально необходимые:

  docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myimage:latest
  

• Избегание монтирования чувствительных директорий хоста

  • Никогда не монтируйте /, /etc, /var/run/docker.sock и другие критичные пути в контейнер без крайней необходимости. Если монтирование требуется, используйте строгие права и опции ro (read-only).

Вывод

Запуск контейнеров от root — это антипаттерн в DevOps-практике, который значительно снижает общую безопасность инфраструктуры. В современных orchestration-системах (Kubernetes, Docker Swarm) и инструментах сборки (Dockerfile, Podman) существуют встроенные механизмы для запуска контейнеров от непривилегированных пользователей. Их использование в сочетании с securityContext, Seccomp, AppArmor и правильной настройкой capabilities позволяет создавать изолированные окружения с минимальной поверхностью для атак. Это не только снижает риски, но и соответствует принципам минимальных привилегий (principle of least privilege), которые являются фундаментом безопасного DevOps.