Всем привет. Сомневаюсь, что кто-то ответит, учитывая что прошлые вопросы

со звёздочкой пришлось разруливать и решать самому, но попробую.

Какие есть способы атаки на хост, имея полный доступ к докер сокету? Демон имеет настройки по умолчанию.
Например я знаю, что можно docker run -it --rm -v /:/host ubuntu:22.04 и так изменить любой файл в системе. Решается через использование subuid/subgid. Какие ещё есть здесь "уязвимости"?

Машина будет общей, то есть с неё будет несколько пользователей ходить и поднимать контейнеры.
"Один дурак сможет поднять/опустить/залезть в любой контейнер" за уязвимость не считаю, меня здесь интересует именно безопасность хоста.

Привет! Хотя в Docker предпринимаются меры для обеспечения безопасности, полный доступ к докер-сокету все же может создавать определенные риски. Вот несколько потенциальных уязвимостей, на которые следует обратить внимание: Привилегии контейнера: При использовании докер-сокета и запуске контейнеров с привилегированными правами (например, опция --privileged), контейнер может иметь доступ к системным ресурсам хоста и выполнение привилегированных действий. Это может стать проблемой, если злоумышленник получит доступ к привилегированному контейнеру. Точки монтирования: Контейнеры Docker могут монтировать файловую систему хоста. Если злоумышленник получает доступ к докер-сокету и может монтировать корневую файловую систему хоста (-v /:/host), то он может изменять файлы и директории на хосте, включая конфигурационные файлы и ключевые системные компоненты. Взаимодействие с другими контейнерами: Если различные пользователи могут поднимать контейнеры на одной машине, это может создать уязвимость. Злоумышленник может попытаться скомпрометировать контейнер, запущенный другим пользователем, и получить доступ к его данным или использовать его как точку отправки атак на другие системы или контейнеры. Уязвимости контейнера: При использовании образов контейнеров, основанных на операционных системах, которые могут иметь известные уязвимости, злоумышленник может использовать эти уязвимости для расширения своих привилегий внутри контейнера и дальнейшей эксплуатации хост-системы. Отслеживание активности: Важно отслеживать активность и журналирование докер-событий. Это поможет определить подозрительную или злонамеренную деятельность, такую как неавторизованное использование докер-сокета или выполнение неправильных команд. Для обеспечения безопасности хоста со всеми пользователями, которые могут использовать Docker, рекомендуется принять следующие меры: Ограничьте доступ к докер-сокету только нужным пользователям или группам. Запускайте контейнеры без привилегий по умолчанию, чтобы минимизировать возможные угрозы. Регулярно обновляйте контейнеры и базовые образы, чтобы закрыть известные уязвимости. Изолируйте контейнеры друг от друга с помощью соответствующих механизмов Docker, например, сетевых namespaces или использования пользовательских namespaces. Обратите внимание, что эти рекомендации не являются исчерпывающим списком, и безопасность Docker-инфраструктуры требует постоянного обновления и применения надлежащих практик.

Ощущаю стиль чатгпт

Да дохуя и больше, но все сведется к одному - создаешь привилегед контейнер и усе

Ну там даже subuid/-gid не особо помогут с некоторой хитростью( Только rootless daemon, а это боль, имхо

Да ваще нет. А на кой тебе такая конфигурация?

Несколько проблем сразу решаю, они между собой никак не связаны. 1) Хочу поднять общий для инстанса гитлаб раннер и дать доступ к хостовому докер сокету, чтобы привычные команды типа docker build работали. Юзерам на инстансе доверяю, но хочется уменьшить импакт в случае каких-то проблем. 2) Есть сервак, но нормально его админить лень. Есть пачка программистов, которым потенциально недоверяю, но хочу, чтобы деплоем занимались чисто они с моим минимальным вмешательством.

Ебашь туда кубер, читай гайды по харденингу от PCI DSS и NSA и живи нормально

Первую проблему думаю решить по-другому, без докера, например через kaniko. Теперь думаю, как запилить безопасный деплой этих самых контейнеров на стороне гитлаб CI. Вторую проблему придётся решать чисто самому, видимо.

Звучит вкусно, но 1) на изучение кубера мной уйдёт некоторое время, а решение надо бы поскорее, хорошо знаю докер и он везде есть 2) прогеры не настолько крутые и вряд ли осилят кубер

Концепции кубера простые, его админить сложно. Но я тебе дал детский вариант. Прогеры освоят, если дрыном ебнуть - практика показывает

Там им будет проще отказаться от написания деплоя, фриланс же

Там деплой простейший

Надо глянуть тогда, вероятно вторая проблема решится, спасибо за совет

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

Ну пара написана на пхп, остальное в основном питон

Да это уже не так важно, важно сколько в сервисе контейнеров

Обычно сам сервис + опционально бдшка рядом, если речь об этом

Ну и нормас

Короче, там все просто - кубер это апи, туда кидаешься запросами. Вот основная концепция - https://kubernetes.io/docs/concepts/workloads/pods/ Поверх нее строятся другие - replicaset чтоб следить, чтобы подов было столько то, а поверх репликасета - деплоймент, чтобы рулить плавным обновлением версии. Для стейтлесс деплоймент всегда используешь. Параллельно репликасету есть стейтфулсет - там имена у подов постоянные и можно указать шаблон для создания аналога вольюма в докере. Это для стейтфул херни. Для сетевого доступа и балансировки есть service - ищет поды по лейблам и балансит трафик между ними, если кинуть запрос на хост с именем сервиса - в кубере есть днс. Сервис может быть и лоадбалансером с внешним ойпи, но тут если тебе нужно выставить через хттп кучу сервисов, то есть ingress - это типа конфига для nginx. Ставишь ингресс-контроллер и он собирает себе конфиг из этих ресурсов и обслуживает все запросы с одного сервиса типа loadbalancer

Спасибо!

Ну там нюансов куча, еще наебешься

сразу видно что кубер попроще докера будет, там где для докера целый гайд надо, то куберу пару строчек достаточно :)

Верю, слышал, морально готов. Осталось время найти)

Тут человек вроде минимально понимает за докер, так что могу опустить кучу подробностей. И это для одной машины. Кубер прям на кластере - это тот еще квест, но лучше ничего нет

внатуре