Доступ к сокету Docker — это root на хосте: что на самом деле даёт его монтирование в контейнер

Что это такое

Документация Docker по безопасности говорит, что демону нужны права root, если не используется режим Rootless, и управлять им следует разрешать только доверенным пользователям. Причина такова: Docker позволяет совместно использовать каталог хоста и контейнера без ограничения прав доступа контейнера, поэтому можно запустить контейнер со смонтированным / хоста и свободно изменять файловую систему хоста.

Unix-сокет /var/run/docker.sock — обычный канал управления. Любой, у кого есть право записи в него, управляет демоном.

Почему это важно

Несколько распространённых конфигураций предоставляют это управление, не называя его так:

• Монтирование сокета в контейнер, чтобы он мог управлять другими контейнерами (исполнители CI, панели управления, обратные прокси, читающие метки, песочницы агентов, запускающие соседние контейнеры). Компрометация такого контейнера становится компрометацией хоста.
• Группа docker: членство в ней фактически даёт root на машине.
• API по TCP без аутентификации клиента через TLS предоставляет то же самое любому в сети.

Для агентов сокет привлекателен тем, что упрощает задачу «запусти это в контейнере»; одновременно он позволяет песочнице выйти за собственные границы одним вызовом API.

Как применять

• Выясните, в какие контейнеры смонтирован сокет: выполните docker inspect для всех контейнеров и найдите путь сокета среди монтирований.
• Если инструменту нужно только читать метаданные контейнеров, поместите перед сокетом фильтрующий прокси, разрешающий нужные ему конечные точки только для чтения, и смонтируйте его вместо сокета.
• Песочницы агентов, которым необходимо запускать контейнеры, запускайте в режиме Rootless, с отдельным демоном или с границей изоляции в виде виртуальной машины, а не с демоном хоста.
• Ограничивайте группу docker так же строго по числу участников, как список sudoers, и проверяйте их вместе.
• Никогда не открывайте API по TCP без взаимной TLS-аутентификации; предпочитайте доступ к сокету через SSH.

Подводные камни

• Bind-монтирование сокета только для чтения (:ro): оно запрещает заменять файл сокета, но не отправлять через него запросы API.
• Предположение, что пространства имён пользователей или непривилегированный пользователь внутри контейнера помогут: демон, выполняющий запрос, всё равно работает как root.