Зачем запускать контейнер от non-root пользователя и как это сделать?

Docker Compose

По умолчанию процесс в контейнере работает от root, а это тот же uid 0 на хосте; для безопасности в Dockerfile создают отдельного пользователя и переключаются на него инструкцией USER.

Почему root в контейнере опасен

При уязвимости ядра или ошибке монтирования атакующий с uid 0 получает привилегии и снаружи контейнера.
Многие базовые образы уже содержат готового пользователя: у node это USER node.

Как сделать правильно

RUN addgroup -S app && adduser -S app -G app
COPY --chown=app:app . /app
USER app

Переключайтесь после всех привилегированных операций сборки, но до запуска приложения.
Файлам нужен владелец через --chown, иначе приложение не сможет в них писать.

Дополнительные меры

read_only: true и cap_drop: [ALL] в Compose, профили seccomp и AppArmor.
Сканирование образа на уязвимости: trivy или docker scout.

Коротко для собеседования

Root внутри контейнера — это uid 0 ядра хоста, так что уязвимость или неудачный mount дают атакующему реальные привилегии. Поэтому создают пользователя, выдают ему файлы через --chown и включают USER после привилегированных шагов сборки, а в Compose добавляют cap_drop и read-only файловую систему.