Pull to refresh

Comments 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 абсолютно бесполезен. Аргументы?


  1. Кубернетес его не использует: https://stackoverflow.com/questions/41475088/when-to-use-docker-healthcheck-vs-livenessprobe-readinessprobe
  2. контейнер с за'fail'енной пробой все равно будет работать, если не применять костыли… вроде https://hub.docker.com/r/willfarrell/autoheal/
    А с ним я имел много приятных минут, когда он ломал деплой (ес-но — контейнер убивался, он его восстанавливал старой версии и все разваливалось).
Only those users with full accounts are able to leave comments. Log in, please.