Почему бытует мнение, что docker добавляет безопасности?

ППКС
А по поводу ответа мне, то мне лениво начинать спорить. К тому же я облажался, использовав слово «проще».

А просто пользоваться образами проверенных мэнтейнеров вместо zver cd? IMHO косяки прут от всяких васьпупкиных, которые осилили регистрацию на докерхабе и решили заявить о себе миру.

https://security.stackexchange.com/questions/106860/can-a-root-user-inside-a-...

Приорал с коментов неслабо!

Как-то не уследил за твоей мыслью - где WAF и где docker? Ты же не сравниваешь WAF и виртуалки.

Как там в 2000х ? Docker EE загугли наконец.

Ну так или иначе, но безопасности он не добавляет, уже выяснили.

В остальном, время покажет)

Тут есть два момента. А должен добавлять? Это же не какая-то серебряная пуля - один докер от всех проблем и зрение улучшает кстати тоже (на самом деле нет). Второй - набивший оскомину chroot добавляет безопасности? Примерно в той же мере добавляет ее докер.

На самом деле, ещё можно сюда добавить возможность унификации деплоймента совершенно разнотипных приложений. Конечно, это применимо только при наличии таких приложений.

кто запрещает не обновлять либы/приложение без контейнеров? К обычным серверам это замечание тоже применимо.

Судя по ссылке, речь идет о древних временах; с тех пор ситуация поменялась. В конце, кстати, коммент:

Worth noting that with Docker 1.10+ and User namespacing, the root user inside a container is no longer the root user outside of the container. whilst that reduces the risk of breakout, it also prevents this scenario of loading a kernel module as the root user inside the container wouldn't have the appropriate rights outside the container. – Rоry McCune Feb 12 '16 at 18:20

Можно информацию посвежее и поконкретнее (без абстракций на тему «а вот если у вас будет эксплоит...»)?

Давайте рассмотрим два примера.

Первый: при сборке образа, запуске контейнера и т.п. всё сделанно грамотно с т.з. безопасности, все возможные рекомендации выполнены. Насколько docker (lxc) в этом случае повысит безопасность? Можно ли будет выйти из контейнера? Допустим, система патченная и 0-day ядерного экспоита у нас нет.

Второй: допущены явные ошибки в настройке. Вопрос: где нужно накосячить, что бы можно было выйти из контейнера?

Сам ищи. Ключевые слова Docker container breakout

Конечно в последнее время многое поменялось. В первую очередь потому что появились способы позволяющие _дополнительно_ обернуть контейнеры в какие-то namespace, добавить SELinux политики и т.п., и различные best practices как не отстреливать себе ногу.

То есть речь не о том что вообще в принципе нельзя построить относительно безопасную систему даже с контейнерами. Но просто контейнеризация сама по себе не является механизмом обеспечения безопасности. От того что ты упаковал приложение в контейнер безопаснее оно не становится. Поэтому «для секьюрности» приложения в контейнеры не раскладывают.

Контейнеры имеет смысл использовать для operability, быстроты обновления и доставки и т.п. А безопасность к ним надо прикручивать как и везде.

В первую очередь потому что появились способы позволяющие _дополнительно_ обернуть контейнеры в какие-то namespace,

что это значит, учитывая что во всех этих фронтендах контейнер это namespaces + cgroups для контроля и ограничения ресурсов?

Как я понимаю namespaces бывают разные.

https://opensource.com/business/14/7/docker-security-selinux

The biggest problem is everything in Linux is not namespaced. Currently, Docker uses five namespaces to alter processes view of the system: Process, Network, Mount, Hostname, Shared Memory.

....

Major kernel subsystems are not namespaced like:

SELinux Cgroups file systems under /sys /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus Devices are not namespaced:

/dev/mem /dev/sd* file system devices Kernel Modules

Статья 2014 года, так что с тех пор вроде как появились user namespaces, которые позволяют отвязать тот root, что внутри контейнера, от того root, что снаружи.

Но все равно я понял, что концептуально «безопасность» это не есть задача контейнерной виртуализации.

там еще проблема что многие модули ядра не знают ничего о namespaces (причина существования openvz и требования специально обученного конфиги для него). Впрочем за последние годы из openvz много патчей попало в ядро. Когда я с докером в первый раз сталкивался там вроде уже была поддержка user namespace.

docker fun detected

обнаружена забава докера?

Когда я с докером в первый раз сталкивался там вроде уже была поддержка user namespace.

Она в 1.10 появилась. И по умолчанию выключена.

Угу, буковку не ту вставил. Но тогда можно «докер вентилятор обнаружен».

https://9gag.com/gag/349747/i-m-a-huge-metal-fan

О, прикольно, именно так. Сохраню.

Нет, если делать все образы самостоятельно с нуля, унифицированным способом и пользоваться только приватным registry, то всё будет нормально и понятно. Это на самом деле единственный верный способ использования докера в продакшене, но он нифига не простой. И далеко не все докероюзеры это понимают.

Люто, даже бешено, плюсую. Два чая этому господину.

Докер-белка, брось пожалуйста ссылку как в контейнерах решается проблема «PID 1»