Docker Privileged VS Non-privileged

Давай сразу к примерам:

Non-privileged

Ты ребёнок, тебя посадили в песочницу, дали совок и формочки, сказали — слышь еблан, играть можно только здесь!

Ты можешь:

— лепить куличики и кренделя — копать ямки и могилки для жуков — сыпать песочек в глаза другим детям — строить свой маленький мир

Ты не можешь:

— вылазить из песочницы — пойти на стройку и доебывать сторожа — насрать в ладошку и кидаться этим в людей — послать всех нахуй и сделать по-своему

Ты работаешь строго в пределах песочницы. Безопасно, предсказуемо, контролируемо, изолировано. Ты бездушный non-privileged контейнер.

Privileged

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

Всё это происходит, когда ты запускаешь:

docker run --privileged

Твой контейнер может:

— управлять сетевыми интерфейсами хоста — лезть в /dev — монтировать что угодно куда угодно — работать как полноценная виртуалка — запускать systemd, модифицировать ядро, iptables, модули и т.п

То есть, это уже не ребёнок в песочнице, а ребёнок со швейцарским армейским ножом, запертый в серверной.

Non-privileged (обычный контейнер)

  • Ограниченный доступ к Linux capabilities
  • Нет доступа к аппаратным устройствам
  • Нет прав на управление сетью хоста
  • Запуск отдельных процессов, а не мини-ОС
  • Работает в namespace’ах и cgroup’ах изоляции

Используется для:

  • веб-сервисов
  • приложений
  • баз данных
  • CI/CD runner’ов (если привилегия не нужна)
  • всего, что «из коробки» работает в Docker

Privileged (контейнер-всевластия)

  • Доступ ко всем Linux capabilities
  • Может лезть в /dev, работать с устройствами
  • Может менять сетевые интерфейсы хоста
  • Может работать как виртуалка
  • Может запускать systemd
  • Может сломать или убить сеть, firewall и модули ядра

Используется для:

  • контейнеров, которым нужны реальные устройства
  • low-level инструментов: tcpdump, wireshark, iptables
  • Docker-in-Docker в особых сценариях
  • Kubernetes kubelet / CNI плагины
  • экспериментов, когда нужен «полный root над всем»

Что выбрать?

Мой алгоритм:

В большинстве случаев лучше выдать минимум необходимых прав, чем сразу открывать ящик Пандоры.

Роман Шубин
Роман Шубин
CEO & CTO, Главред в «Цифровой улей»
Задать вопрос
Ну и для отладки privileged прям мастхев, чтобы исключить какие-то внешние факторы, от которых могут лезть баги.

На днях продолжим…