Comments 4
Интересно, но будто бы при компрометации root вам это не поможет, перехватить такой секрет в процессе или просто из памяти не выглядит сложной задачей.
P.S. Кто-то нынче использует swarm? :)
Ну если скомпрометирован root на swarm leader ноде - то да, всё грустно, все секреты можно достать. Если же на воркере - то придётся подумать. Хотя, возможно, docker exec будет доступен.
Перехватить из памяти - возможно, но это ещё иди поищи где у этого постгреса он там хранится. Меня, в первую очередь, напрягало, что у сервиса, который работает неделями, просто доступен текстовый файлик с паролями. Хотелось его убрать когда он уже не нужен.
Я swarm использую вполне. Не очень он развивается, конечно, но для k8s у меня ресурсов нет.
Хотя, возможно, docker exec будет доступен.
При наличии root вы и без docker exec (который будет доступен) сможете получить доступ в любой namespace.
для k8s у меня ресурсов нет
Вычислительных или человеческих? Kube довольно экономичен на небольших сетапах, да и есть всякие k3s. Зато там вам доступен, например, external secrets operator.
Да, согласен, root на хосте сможет всё. Поэтому на хосте я ставлю только докер. Однако, в контейнере можно, случайно, заиметь какой-нибудь стилер, который переменные окружения и все конфиги соберёт.
Я тот ещё параноик и тоже могу придумать ещё штук 5 сценариев, где советы из моей статьи не помогут, но всё же это лучше чем в открытом виде их держать.
До недавнего времени я был в компании один за всю IT часть и кубер мне показался слишком тяжёлым в обслуживании. Swarm довольно прост и я уже для его API написал пару инструментов для автоматизации.
Секреты Docker Swarm: как сделать их одноразовыми с помощью именованных каналов (FIFO)