Будет ли созданный на хостовой системе пользователь доступен в контейнере?

Взаимодействие пользователей между хостом и контейнером

Короткий ответ: НЕТ, пользователь, созданный на хостовой системе, по умолчанию не будет автоматически доступен внутри контейнера Docker. Контейнеры имеют свою изолированную пространство пользователей (user namespace), которая отделена от системы хоста.

Почему пользователи изолированы?

Docker-контейнеры построены на принципах изоляции процессов, файловой системы, сети и пользователей. Каждый контейнер использует свою собственную таблицу пользователей и групп (реализованную через /etc/passwd и /etc/group внутри контейнера). По умолчанию Docker использует механизм user namespace mapping, где UID (User ID) и GID (Group ID) из контейнера могут быть сопоставлены с другими UID/GID на хосте для усиления безопасности, но это одностороннее отображение, а не общая база пользователей.

Как UID/GID работают на практике

Хотя имя пользователя недоступно, соответствующий UID может быть виден и использован, если он совпадает численно. Пример:

# На хосте создаем пользователя с UID 1005
sudo useradd -u 1005 hostuser

# Запускаем контейнер и проверяем
docker run --rm alpine id 1005

Вывод很可能 будет uid=1005(?), потому что в минимальном образе Alpine нет записи для пользователя с UID 1005 в /etc/passwd, но система распознает числовой идентификатор. Чтобы имя пользователя тоже было доступно, его запись должна существовать внутри контейнера.

Способы сделать пользователя доступным в контейнере

1. Создание пользователя внутри контейнера при сборке образа (наиболее распространенный способ):

   FROM ubuntu:22.04
   RUN useradd -m -u 1005 -s /bin/bash myuser
   USER myuser
   

2. Монтирование файлов /etc/passwd и /etc/group с хоста в контейнер (не рекомендуется для продакшена из-N -за проблем безопасности и переносимости):

   docker run -v /etc/passwd:/etc/passwd:ro -v /etc/group:/etc/group:ro ubuntu id hostuser
   

3. Использование --user для указания конкретного UID/GID при запуске:

   docker run --user 1005:1005 ubuntu whoami
   

    Команда `whoami` может не работать без записи в `/etc/passwd`, но процессы будут запускаться от этого UID.

1. Настройка пользовательских пространств имен (user namespace remapping) в демоне Docker для постоянного отображения UID — это более сложная настройка на уровне Docker Engine.

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

• Root в контейнере ≠ Root на хосте: По умолчанию root в контейнере (UID 0) сопоставляется с непривилегированным пользователем на хосте (часто UID в диапазоне 100000+), что снижает риски.
• Проблемы с общими файлами: Если контейнер и хостовая система работают с общими томами (volumes), важно согласовать UID/GID для правильных прав доступа к файлам.
• Рекомендация: Лучшая практика — явно определять пользователей внутри Dockerfile и использовать не-root пользователей для запуска процессов.

Пример решения для доступа к файлам на общем томе

# На хосте: файлы принадлежат UID 1001
mkdir shared_data
sudo chown 1001:1001 shared_data

# В Dockerfile:
FROM alpine
RUN adduser -D -u 1001 containeruser
USER containeruser

# Запуск с монтированием тома:
docker run -v $(pwd)/shared_data:/data myimage

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