Комментарии 7
Перевод отличный, но интересно узнать ваше мнение. Собственное. Потому что многие вещи, описанные в статье… ну, спорные…
Например, live-restore. Отличный способ себе пострелять по ногам, когда радикально меняются настройки докер демона (я не проверял, но есть подозрение, что та же смена storage driver + liverestore все сломает).
Еще есть как минимум два сценария использования докера — на машине разработчика в режиме разработки и на тестовых/промышленных средах. А вот для последних рекомендации актуальны. Вряд ли кто-то будет бридж на машине разработчика спуфить )
По вашему примеру с live-restore. Предполагаю, что да — эта проблема имеет место быть, НО! в реальности часто ли вам приходится менять те же storage driver? Почему нельзя мигрировать контейнеры на новые ноды с новым storage driver и потом на старых нодах провести работы. Если вы собираетесь делать такие вещи и знаете, что вы выставили live-restore.
Потому что, очевидно, нет понятия миграции контейнеров. Они же иммутабельные и созданы, чтобы умирать. Это раз.
Два — это подразумевает кластерное решение вроде кубернетеса. А там свой процесс. И более того — свои особенности. И докИр там не нужен.
Я уж не говорю о том, что есть вероятность, что не все контейнеры управляются оркнстратором типа кубернетеса. Например, ранчер любит системные компоненты вроде кьюьлета запускать в докере вне куба. А не в системди сервисе.
Три — мне показалось, или это так и есть, но автор рассматривал безопасность именно standalone docker нод
Никогда не запускайте сокет Docker'а внутри контейнера.
— гугл транслейт, ты ли это?
Конфиденциальные данные должны храниться как секреты. Запустить соответствующий сервис можно с помощью команды docker service create
я ошибаюсь или docker service доступен только если хост в режиме Swarm? Т.е. «просто так» этого не сделать. Может стоит указывать такое в тексте?
Healthcheck (проверка работоспособности) — мощный инструмент, позволяющий проверять целостность контейнера.
мне кажется, к теме безопасности (равно как и целостности контейнера) это не относится. Вызов какого-то скрипта (утилиты) Healthcheck это лишь проверка «работает ли процесс внутри контейнера должным образом». И то — если такая возможность представляется самим процессом. Как это повышает безопасность?
Я бы еще добавил пункт о том, что пользователь хоста, имеющий доступ к сокету Докера (или иным способом имеющий возможность управлять контейнерами) по сути имеет полный доступ к хосту.
Как пример — включение в группу docker (без включения возможности sudo) позволяет прокинуть в контейнер корень ФС и изнутри контейнера спокойно «что-то запрещенное почитать\исправить».
DOCKER HEALTHCHECK абсолютно бесполезен. Аргументы?
- Кубернетес его не использует: https://stackoverflow.com/questions/41475088/when-to-use-docker-healthcheck-vs-livenessprobe-readinessprobe
- контейнер с за'fail'енной пробой все равно будет работать, если не применять костыли… вроде https://hub.docker.com/r/willfarrell/autoheal/
А с ним я имел много приятных минут, когда он ломал деплой (ес-но — контейнер убивался, он его восстанавливал старой версии и все разваливалось).
Безопасность для Docker-контейнеров