Запуск контейнера от root нарушает принцип наименьших привилегий: при взломе приложения атакующий сразу получает максимум прав внутри контейнера и сильно упрощает выход на хост.
Особенно это опасно при пробросе томов, системных сокетов и выдаче дополнительных привилегий ядра.
Поэтому в продакшене стараются запускать контейнеры под отдельным непривилегированным пользователем и минимизировать выданные права.
По умолчанию пользователь root внутри контейнера соответствует root на хосте (если не настроены user namespaces). Это означает, что уязвимость в приложении внутри контейнера быстро превращается в риск компрометации всей хост-системы, особенно если контейнеру уже выданы дополнительные привилегии (например, флаг --privileged, доступ к /var/run/docker.sock или монтирование системных директорий).
Основные проблемы запуска контейнера от root:
Хорошей практикой считается запускать приложение в контейнере под отдельным непривилегированным пользователем, заранее подготовив права на файлы и порты. Это можно задать прямо в образе через директиву USER в Dockerfile, чтобы любой запуск этого образа по умолчанию был непривилегированным.
Ниже пример Dockerfile, в котором создаётся отдельный пользователь и от его имени запускается процесс:
Даже если образ изначально настроен не идеально и внутри него всё запускается от root, это можно исправить на этапе запуска контейнера, явно указав UID/GID пользователя. Такой подход особенно полезен при работе с чужими, недоверенными образами.
В итоге запуск контейнеров от root имеет смысл только в узких системных сценариях и под жёстким контролем. В обычных сервисах безопасный базовый подход — непривилегированный пользователь, отказ от --privileged, минимальный набор capabilities, аккуратная работа с томами и сетевыми настройками.
Отметьте свой прогресс