Как задать права доступа к mount в Docker

Настройка прав доступа к mount в Docker

В Docker управление правами доступа к mounted томам и bind-монтированиям является критически важным аспектом для безопасности и корректной работы контейнеров. Существует несколько подходов, каждый из которых имеет свои нюансы.

1. Использование аргументов монтирования при запуске контейнера

Наиболее прямой способ — указание параметров -v или --mount с настройкой владельца и прав:

# Указание прав через -v (классический синтаксис)
docker run -v /host/path:/container/path:ro,uid=1000,gid=1000,umask=022 myimage

# Более современный синтаксис --mount
docker run \
  --mount type=bind,source=/host/path,target=/container/path,readonly,consistency=cached \
  myimage

# Для named volumes можно использовать драйвер local с опциями
docker volume create --driver local \
  --opt type=none \
  --opt device=/host/path \
  --opt o=bind,uid=1000,gid=1000 myvolume

2. Конфигурация в Docker Compose

В Docker Compose настройки прав доступа задаются в docker-compose.yml:

version: '3.8'

services:
  app:
    image: myapp:latest
    volumes:
      # Bind mount с указанием прав
      - type: bind
        source: ./data
        target: /app/data
        read_only: true
        bind:
          create_host_path: true
          propagation: rshared
      
      # Named volume с опциями
      - type: volume
        source: mydata
        target: /app/storage
        volume:
          nocopy: false
      
      # Tmpfs volume (в памяти) с правами
      - type: tmpfs
        target: /tmp
        tmpfs:
          size: 1000000000  # 1GB
          mode: 1777        # sticky bit + rwx для всех

volumes:
  mydata:
    driver: local
    driver_opts:
      type: none
      device: /host/storage
      o: bind,uid=1000,gid=1000,mode=0755

3. Внутриконтейнерная настройка

Права можно настроить и внутри контейнера, но это требует соответствующих привилегий:

# Запуск контейнера с привилегиями для изменения прав
docker run --privileged myimage

# Или с более гранулярными правами
docker run --cap-add CHOWN --cap-add FOWNER myimage

# Внутри Dockerfile можно установить владельца
FROM alpine:latest
RUN mkdir -p /data && chown -R 1000:1000 /data
VOLUME /data
USER 1000

4. Решение проблем с пользователями и группами

Ключевая проблема — mismatch UID/GID между хостом и контейнером. Решения:

• Использование совпадающих UID/GID: Создание пользователя в контейнере с тем же UID, что и на хосте
• Динамическая настройка: Запуск entrypoint-скрипта, который меняет права при старте:

#!/bin/bash
# entrypoint.sh
chown -R appuser:appgroup /data
exec "$@"

FROM alpine:latest
RUN addgroup -g 1000 appgroup && adduser -D -u 1000 -G appgroup appuser
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["myapp"]

5. Безопасность и лучшие практики

• Принцип наименьших привилегий: Всегда используйте минимально необходимые права
• Read-only монтирования: По возможности монтируйте директории только для чтения
• Изоляция sensitive данных: Критичные данные монтируйте с ограниченными правами
• SELinux/AppArmor: На системах с мандатной защитой используйте соответствующие контексты:

# SELinux context для Docker volumes
docker run -v /host/path:/container/path:z myimage  # shared context
docker run -v /host/path:/container/path:Z myimage  # private unshared context

6. Продвинутые сценарии

Для сложных случаев можно использовать:

# User namespace remapping (переопределение пространства имён пользователей)
dockerd --userns-remap="default"

# Overlay2 storage driver с опциями
docker run --storage-opt overlay2.override_kernel_check=1 \
  -v /data:/data:shared,uid=1000 myimage

# Использование docker volume plugins с поддержкой ACL
docker plugin install vieux/sshfs
docker volume create -d vieux/sshfs \
  -o sshcmd=user@host:/remote/path \
  -o uid=1000 -o gid=1000 sshvolume

Рекомендации по выбору метода

1. Для разработки: Используйте простые bind mounts с явным указанием UID/GID
2. Для production: Предпочитайте named volumes с настроенными драйверами
3. Для конфигураций: Read-only mounts для конфигов и секретов
4. Для данных приложения: Volumes с правильным владельцем и группой
5. Для временных данных: tmpfs mounts с ограничением размера

Правильная настройка прав доступа предотвращает множество проблем: от ошибок записи до уязвимостей безопасности. Всегда тестируйте конфигурацию в изолированной среде перед развертыванием в production.