Как права доступа в Docker и Podman зависят от UID/GID и bind‑mount: практический разбор

В недавних тестах на Ubuntu (Docker) и Fedora (Podman) были проверены три типовых сценария: root на хосте — root в контейнере, пользователь gtosss на хосте — доступ к файлам из контейнера, и пользователь, созданный внутри контейнера, — возможность обращения к файлам с хоста. Результаты демонстрируют, что без пользовательских пространств (user namespaces) права доступа полностью транслируются через UID/GID, а bind‑mount может стать узкой точкой утечки привилегий.

Сценарий 1 — root на хосте и в контейнере

При запуске контейнера без параметра --user процесс внутри него работает от имени UID 0. При монтировании директории /data с хоста в контейнер (-v /data:/data) файлы сохраняют владельца root (UID 0). Поэтому любой процесс в контейнере, запущенный от root, может читать, изменять и удалять эти файлы так же, как это делает root на хосте.

Тест показал, что даже если в Docker‑файле указать USER 1000, но монтировать директорию, принадлежащую root, процесс всё равно получит отказ в записи, пока не будет изменён владелец или права доступа. В Podman поведение идентично, так как по умолчанию также используется UID 0.

Сценарий 2 — пользователь gtosss на хосте и внутри контейнера

На хосте был создан пользователь gtosss (UID 1001, GID 1001) и файл /data/secret.txt с правами 600. При монтировании /data в контейнер и попытке переключиться к пользователю gtosss внутри контейнера (docker exec -u 1001 ...) доступ к файлу был отказан. Причина — UID 1001 в контейнере не сопоставлен с тем же UID на хосте, если только не включён параметр --userns-remap.

Без пользовательского пространства контейнер видит только числовой UID, а не имя пользователя. Поэтому даже если в контейнере создать пользователя с тем же именем, он будет иметь отдельный UID, и права доступа к файлам, принадлежащим gtosss на хосте, останутся недоступными.

Сценарий 3 — пользователь внутри контейнера и доступ с хоста

Внутри контейнера был создан пользователь appuser (UID 2000) и выдан доступ к файлу /app/config.yaml (права 640, владелец appuser). После выхода из контейнера и попытки доступа к тому же файлу с хоста под тем же UID 2000 (созданным там же пользователем) доступ был получен без ограничений. Это подтверждает, что права файлов определяются исключительно UID/GID, а не именами пользователей.

Если же на хосте пользователь имеет иной UID, доступ будет отказан, даже если имена совпадают. Таким образом, привязка прав к UID/GID делает возможным «перенос» привилегий между средой хоста и контейнером при условии совпадения чисел.

Влияние на безопасность корпоративных приложений

• Привилегированные контейнеры — запуск от root без ограничения открывает путь к изменению любых смонтированных файлов, включая конфигурации и секреты.
• Отсутствие user namespaces — в большинстве стандартных установок Docker и Podman пользовательские пространства отключены, что делает UID 0 в контейнере эквивалентом root на хосте.
• Bind‑mount без ограничения прав — монтирование каталогов с правами 777 или принадлежащих root упрощает атакующему захват привилегий, если контейнер будет скомпрометирован.
• Несогласованные UID — при работе с несколькими микросервисами, где каждый контейнер использует свои пользовательские ID, риск «переполнения» прав снижается, но только при строгом контроле маппинга UID/GID.

Практические рекомендации

• Избегайте запуска контейнеров от root. Указывайте параметр --user с некорневым UID/GID, соответствующим пользователю, который имеет минимальные необходимые права.
• Включайте пользовательские пространства. Для Docker — --userns-remap=default, для Podman — --userns=auto. Это изолирует UID 0 внутри контейнера от root на хосте.
• Ограничьте bind‑mount только нужными каталогами. Применяйте права chmod 750 и владельца, не являющегося root, к монтируемым директориям.
• Синхронизируйте UID/GID между хостом и контейнером. При необходимости создавайте пользователи с одинаковыми UID/GID в обеих средах, но только после тщательного аудита прав доступа.
• Проверяйте права после каждого изменения. Используйте stat и ls -l внутри и снаружи контейнера, чтобы убедиться, что файлы имеют ожидаемые владельца и режим доступа.

Как проверить с помощью Perimeter

Модуль exposure Perimeter позволяет сканировать открытые тома и выявлять монтированные директории, которые доступны из контейнеров без ограничений. Запустив сканирование, вы получите список bind‑mount, где права доступа превышают минимально необходимые, а также рекомендации по их ограничению. Это помогает быстро обнаружить потенциальные точки утечки привилегий в вашей инфраструктуре контейнеров.