Под каким пользователем поднимается Docker контейнер

Question

deepseek-v3.2 · Accepted Answer

## Пользователь по умолчанию и управление в Docker контейнерах

В Docker контейнерах **процессы по умолчанию запускаются от имени пользователя root** (с UID 0), если не указано иное. Однако это поведение можно и нужно контролировать в целях безопасности.

### Основные механизмы управления пользователем

1. **Инструкция USER в Dockerfile**:
   Эта инструкция устанавливает, от имени какого пользователя будут запускаться последующие команды (RUN, CMD, ENTRYPOINT) в данном слое образа.

```dockerfile
   # Создаём непривилегированного пользователя в образе
   RUN groupadd -r appuser && useradd -r -g appuser appuser
   # Переключаемся на него
   USER appuser
   # Запускаем приложение
   CMD ["python", "app.py"]
   ```

2. **Флаг `--user` в команде `docker run`**:
   Позволяет переопределить пользователя при запуске контейнера, даже если в образе задан другой.

```bash
   docker run --user 1000:1000 my-image:latest
   ```
   Здесь `1000:1000` — это UID (User ID) и GID (Group ID) пользователя и группы на хостовой системе.

### Важность непривилегированного пользователя

Запуск от **root внутри контейнера создаёт серьёзные риски безопасности**:
*   Если злоумышленник скомпрометирует процесс в контейнере, он получит права root **внутри пространства имён контейнера**.
*   Примонтированные volumes (особенно с чувствительными данными) становятся уязвимы.
*   В случае уязвимостей в ядре или ошибок конфигурации, возможен **побег из контейнера (container escape)** на хост, где процесс также будет иметь root-права.

**Рекомендация**: всегда создавайте и используйте непривилегированного пользователя в production-образах.

### Сложности с пользователями и способы их решения

Проблема возникает, когда UID внутри контейнера не соответствует UID на хосте. Например, процесс в контейнере записывает файлы в volume, и на хосте они принадлежат неизвестному UID.

**Решение 1: Фиксация UID при сборке образа**:
```dockerfile
ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser
USER appuser
```
Теперь контейнер всегда запускается с известным UID=10001.

**Решение 2: Динамическое сопоставление через `--user`**:
Используем `docker run --user $(id -u):$(id -g)`, чтобы запустить контейнер от текущего пользователя хоста.

**Решение 3: Использование **user namespace remapping** (пространства имён пользователей)**:
Более безопасный и глобальный подход на уровне Docker daemon (`/etc/docker/daemon.json`).
```json
{
  "userns-remap": "default"
}
```
При этом все UID/GID внутри контейнера будут отображаться на непривилегированный диапазон на хосте (например, начало с 100000), изолируя хост ещё надёжнее.

### Особенности в Kubernetes (K8s)

В K8s политика безопасности определяется **SecurityContext** для pod или контейнера:
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false
```
*   **runAsUser / runAsGroup**: UID/GID для запуска процессов.
*   **fsGroup**: GID, используемый для смонтированных volumes (меняет владельца).

Для максимального ограничения прав используется **Pod Security Standard (PSS)** или **admission controllers** (например, **PodSecurityPolicy** в старых версиях), которые могут форсировать запуск без root, запрещать привилегированные контейнеры и т.д.

### Вывод

Хотя **контейнер по умолчанию запускается от root**, современные best practices в DevOps и DevSecOps категорически требуют отказываться от этого. Ключевые шаги:
1.  Создание непривилегированного пользователя на этапе сборки образа.
2.  Использование инструкции `USER` в Dockerfile.
3.  Дальнейшее ограничение прав через флаги запуска (`--user`) или, что более важно, через механизмы оркестратора (Kubernetes **SecurityContext**, **seccomp**, **AppArmor** профили).
4.  Рассмотрение **user namespace remapping** для дополнительной изоляции в окружениях с высокими требованиями к безопасности.

Такой подход значительно снижает **атакующую поверхность (attack surface)** и соответствует принципу **минимальных привилегий (principle of least privilege)**, что критически важно для production-сред.

Под каким пользователем поднимается Docker контейнер

Комментарии (2)

Пользователь по умолчанию и управление в Docker контейнерах

Основные механизмы управления пользователем

Важность непривилегированного пользователя

Сложности с пользователями и способы их решения

Особенности в Kubernetes (K8s)

Вывод