Что такое --privileged и почему его никогда не используют в проде «просто так»?

Что делает --privileged

Флаг --privileged снимает почти все изоляционные механизмы ядра для контейнера:

• Отключает AppArmor и seccomp-профили.
• Предоставляет все Linux capabilities (включая CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_MODULE и ещё ~38 других).
• Монтирует /dev хоста целиком — контейнер видит все блочные устройства, диски, GPU и т.д.
• Снимает ограничения cgroup namespace — процесс видит cgroup хоста.

# Обычный контейнер
docker run --rm alpine capsh --print | grep Current
# Current: cap_chown,cap_dac_override,cap_fowner,...  (14 capabilities)

# Привилегированный
docker run --privileged --rm alpine capsh --print | grep Current
# Current: =ep  (все ~40 capabilities)

# Видны устройства хоста
docker run --privileged --rm alpine ls /dev | wc -l
# 100+

Почему это опасно в проде

Привилегированный контейнер — это фактически побег из контейнерной изоляции. С CAP_SYS_ADMIN можно:

• Смонтировать файловую систему хоста: mount /dev/sda1 /mnt прямо из контейнера.
• Загрузить kernel module: insmod evil.ko.
• Изменить параметры ядра через /proc/sys.
• Выйти из namespace через nsenter или unshare.

# Классический container escape через --privileged
docker run --privileged --rm -it alpine sh
# Внутри контейнера:
mkdir /mnt/host
mount /dev/sda1 /mnt/host
chroot /mnt/host
# Теперь у нас root-shell на хосте

Что использовать вместо --privileged

В большинстве случаев нужна одна-две capability, а не все сразу.

# Вместо --privileged: добавить только нужные capabilities
docker run \
  --cap-add NET_ADMIN \
  --cap-add SYS_PTRACE \
  my-image

# Убрать ненужные из дефолтного набора
docker run \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  my-image

# docker-compose.yml
services:
  app:
    image: my-image
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true

Легитимные use-cases для --privileged

• CI-агенты, запускающие Docker внутри Docker (DinD) — и даже тут лучше использовать socket mount + rootless Docker.
• Загрузка kernel modules (eBPF-инструменты: Falco, Cilium в legacy-режиме).
• Контейнеры с прямым доступом к GPU через /dev/nvidiaX (но NVIDIA CDI / device plugin делает это без --privileged).
• Системные утилиты для диагностики (одноразовые, не в проде).

Как обнаружить --privileged в production

# Проверить запущенные контейнеры
docker ps -q | xargs docker inspect \
  --format '{{.Name}} Privileged={{.HostConfig.Privileged}}' \
  | grep 'Privileged=true'

# В Kubernetes: policy через OPA Gatekeeper или Kyverno
# Встроенный PodSecurityPolicy (deprecated) или Pod Security Admission
# restricted profile запрещает privileged: true в спеке

Подводные камни

• seccomp отключается полностью — даже если вы написали кастомный seccomp-профиль, --privileged его игнорирует.
• AppArmor профиль docker-default тоже снимается — контейнер может делать системные вызовы, которые в норме блокируются.
• Kubernetes не пропустит --privileged без явного разрешения — Pod Security Admission (restricted/baseline) блокирует securityContext.privileged: true. Не рассчитывайте перенести DinD-пайплайн в k8s без переработки.
• Docker socket mount опаснее, чем кажется — монтирование /var/run/docker.sock без --privileged тоже даёт root на хосте через API Docker.
• --privileged не нужен для bind mount — многие думают, что для монтирования томов нужен --privileged. Нет: bind mounts работают без него.
• Rootless Docker снижает риск — если демон работает от обычного пользователя, --privileged всё равно не даёт настоящий root на хосте, но это не повод злоупотреблять флагом.
• Falco/Sysdig детектируют --privileged — в проде с runtime security контейнер сразу поднимет алерт. Настройте правило заранее, а не после инцидента.

• Включать --privileged, чтобы быстро исправить permission denied.
• Не выяснять, какая capability или device реально нужна.
• Запускать privileged app container с production secrets и широкой сетью.

• Объясняет, какие границы ослабляет privileged mode.
• Предлагает least-privilege alternative.
• Учитывает dedicated nodes, audit and threat model.