Comments 13
Отдельно стоит выделить, что при использовании Docker-compose контейнеры подключаются к единой создаваемой сети, и все контейнеры доступны друг для друга.
Да, но в пределах текущего проекта. Разные проекты не имеют доступа друг к другу, если явно это не разрешить через подключение к external network.
Еще стоило бы упомянуть об использовании distroless образов, например отсюда https://github.com/GoogleContainerTools/distroless где в контейнере нет вообще даже шелла, только библиотеки и ваш исполняемый файл. Даже если злоумышленнику удастся проэксплуатировать уязвимость в вашем коде приводящую к исполнению шелл кода, - он не выполнится, т.к. банально нет шелла! Думаю образ gcr.io/distroless/cc-debian11 подойдет большинству приложений
строго говоря distroless (и ограниченного пользователя) недостаточно.
нужно еще правильные права на каталоги и файлы выставлять.
зы
еще беда, в том числе и моего комментария, в том что сообщается о том что делаем, но не сообщается о том зачем делаем
;))
Так вроде никто и не говорит что достаточно - в безопасности вообще не бывает универсальных рецептов и задача заключается в максимальном сокращении области поражения.
Хм, а, условно говоря, ограничение системных вызовов (например, через LD_PRELOAD), в частности open для определенных файлов/директорий закрыло бы эту часть? Может, есть готовые аналоги (помимо SELinux, там хостовая система нужна)?
Метод 6: использовать gVisor в качестве рантайма, чтобы существенно сократить возможность побега из контейнера через уязвимости ядра.
Если в приложении, которое работает в контейнере, будет обнаружена уязвимость, то это может позволить злоумышленникам выйти из контейнера и выполнить различные действия с правами root на хостовой ОС.
Что-то здесь не то. Если такое возможно, то это уже уязвимость самого Docker & containerd.
Нормальное явление, увы - вот например тут об этом подробнее https://habr.com/ru/company/first/blog/650553/
Спасибо за статью, не знал. Для тех кому лень кликать по ссылке - речь идет о запуске контейнеров с правами администратора. О ужас, если запустить контейнер с правами админа, то он получит права админа.
Я думаю, что те кто это делает отлично понимают что делают и для них докер служит не средством изоляции а инструментом для удобного развертывания. Более того, благодаря докеру можно распределить софт между привилегированными контейнерами и обычными, чтобы обеспечить баланс безопасности и функционала или что там нужно для привилегированных контейнеров.
На самом деле (насколько я понимаю) запуск с ключом --privileged под рутом, не то же самое что просто запуск контейнера под рутом. Последнее делают очень часто, а вот запуск с упомянутым ключом достаточно редко. Но лучше конечно когда контейнер запускается под рутом и с минимально достаточным набором прав.
Если в приложении, которое работает в контейнере, будет обнаружена
уязвимость, то это может позволить злоумышленникам выйти из контейнера и
выполнить различные действия с правами root на хостовой ОС.
Так, стоп. Вроде же root в контейнере не равен root хост-машины (в конфигурации по умолчанию)? И выйти из контейнера может позволить не уязвимость в приложении, которое там работает, а уязвимость в ядре системы, выполняющейся на хост-машине?
Не равен, но маппится. Как и любой другой пользователь, созданный в контейнере. Разве что capabilities порезаны.
Всё верно. Только ядро патчить не каждый может и частенько патча нужно ждать. Поэтому для минимизации рисков лучше сразу настроить пользователей, права доступа и опции запуска для контейнера.
Методы обеспечения безопасности контейнеров Docker