Container Escape через Docker Socket Exposure: как не превратить контейнер в «админку» всего сервера

Проброс /var/run/docker.sock внутрь контейнера делает приложение полноценным клиентом Docker API на хосте. На практике это означает возможность запускать и останавливать контейнеры, монтировать директории хоста и управлять сетевой конфигурацией — то есть получать доступ, эквивалентный административному по оценке самой Docker . Если такой контейнер скомпрометирован, «побег» на уровень узла возможен без эксплуатации уязвимостей ядра.

Почему организации до сих пор идут на это? Чаще всего — ради скорости сборок в CI, удобства инструментов управления или «временной» диагностики. Эти сценарии понятны, но цена компромисса высока: контейнер получает возможность выполнять действия, которые обычно доступы только на уровне узла, а удалённый API без корректной защиты превращается в прямую точку входа — его разрешают только с TLS и строгой аутентификацией .

В этой статье разбираем механизм риска при экспонировании сокета, типовые конфигурации, из-за которых он появляется, признаки в Compose и Kubernetes, а также практические способы закрыть проблему: прокси над Docker API с минимально достаточными правами, rootless-режим и user namespaces, политики на уровне платформы и безопасные альтернативы в цепочке сборки.

Цель — дать практичные шаги, которые можно внедрить без радикальной перестройки процессов: от быстрой проверки инфраструктуры до устойчивых политик и мониторинга, помогающих предупредить инцидент ещё на этапе конфигурации.

Что такое Docker socket и почему он критичен

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

Отдельно стоит отметить риск удалённого API Docker по TCP: его можно включать только с шифрованием и аутентификацией клиентов, иначе это эквивалент «административного» порта наружу см. рекомендации по защите доступа .

Почему проброс docker.sock опасен

Монтируя сокет хоста внутрь контейнера, вы передаёте приложению возможность управлять Docker-демоном. Если злоумышленник получает доступ в этот контейнер (RCE, скомпрометированный токен, уязвимая библиотека), то следующий шаг тривиален: запустить новый контейнер с нужными привилегиями, смонтировать директории хоста, изменить сеть. Никаких специальных эксплойтов — достаточно штатного функционала API.

• Контроль контейнеров на узле. Создание, остановка, пересоздание — как для штатного оператора.
• Доступ к файловой системе. Запуск контейнера с монтированием / или нужных директорий хоста.
• Эскалация прав. Старт привилегированных контейнеров, манипуляции с capabilities, сетевые изменения.
• Сокрытие следов. Большинство действий выглядят как легитимные операции Docker API и не всегда сразу бросаются в глаза в журналах.

Типовые источники риска

Проброс сокета редко появляется «сам по себе». Чаще всего это побочный эффект удобства и стремления к скорости.

• CI/CD с «Docker внутри Docker». Раннеру для сборки образов монтируют сокет — и это остаётся в конфигурации надолго.
• Инструменты управления и автообновления. Portainer, Watchtower и аналоги требуют доступ к демону и нередко получают его шире, чем необходимо.
• Диагностика и временные решения. Временный доступ для отладки со временем превращается в постоянную настройку.
• Kubernetes с hostPath. Манифесты, где в Pod подмешан сокет Docker/Containerd (/var/run/docker.sock, /run/containerd/containerd.sock), что нарушает изоляцию и противоречит Pod Security Standards .

Последовательность атаки при наличии доступа к Docker API

Последовательность минималистична: проникновение в контейнер → обнаружение смонтированного сокета → обращение к Docker API → запуск новых контейнеров с нужными монтированиями/правами → доступ к узлу. С технической стороны это стандартные API-вызовы. Поэтому важно предотвращать саму возможность доступа, а не рассчитывать на то, что такие операции останутся незамеченными.

Как обнаружить проблему: проверочный план

Начните с инвентаризации и статического анализа конфигураций. Цель — оперативно найти, где и почему появился проброс.

Docker Compose и одиночные хосты

• Просмотрите файлы Compose на наличие volumes с путём /var/run/docker.sock.
• Проверьте вспомогательные контейнеры (Portainer, Watchtower, раннеры): действительно ли им необходим прямой сокет, в какой области и под чьим пользователем.

Kubernetes

• Ищите hostPath на сокеты рантайма: Docker/Containerd/CRI-O.
• Проверьте, включены ли Pod Security уровня baseline/restricted, и есть ли политика, блокирующая подобные монтирования.

Статический анализ IaC

• Используйте сканеры конфигураций: Trivy Config , Checkov , KICS . В их правилах есть сигнатуры на опасные hostPath и доступ к сокетам.

Журналы и телеметрия

• Включите аудит Docker/Kubernetes: фиксируйте создание контейнеров, добавление монтирований, изменение сетей. Это позволяет заметить злоупотребления.
• Отслеживайте обращения к удалённым портам 2375/2376 и внутренним Unix-сокетам через средства наблюдения.

Меры предотвращения: как снизить риск без радикальной перестройки процессов

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

Избегайте прямого доступа к демону

Для сборок используйте инструменты, которые не требуют docker.sock:

• Kaniko — сборка образов без доступа к демону, публикация напрямую в реестр.
• Docker BuildKit в изолированном или rootless-режиме: кэш, параллелизм, без прямого доступа к хосту.
• Podman и Buildah — альтернативы для ряда сценариев сборки и управления контейнерами.

Если доступ всё же нужен — ограничьте его прокси и RBAC

Не выдавайте контейнеру «голый» сокет. Поставьте прокси над Docker API и включите только необходимые эндпоинты. Популярный вариант — docker-socket-proxy , где права включаются по переменным окружения (подход «белых списков»).

Rootless Docker и user namespaces

Запуск демона без прав суперпользователя снижает последствия компрометации. Совместите с user namespaces, чтобы UID внутри контейнера маппился на непривилегированный UID на хосте Rootless Docker , userns-remap .

Политики на уровне платформы

Запретите опасные монтирования централизованно: даже если кто-то попытается — платформа отклонит запрос.

Kyverno (пример политики)

{ "apiVersion": "kyverno.io/v1", "kind": "ClusterPolicy", "metadata": { "name": "deny-runtime-sockets" }, "spec": { "validationFailureAction": "enforce", "rules": [{ "name": "block-runtime-sockets", "match": { "resources": { "kinds": ["Pod"] } }, "validate": { "message": "Монтирование сокетов рантайма запрещено", "deny": { "conditions": { "any": [{ "key": "{{ request.object.spec.volumes[].hostPath.path || '' }}", "operator": "AnyIn", "value": ["/var/run/docker.sock","/run/containerd/containerd.sock","/var/run/crio/crio.sock"] }] } } } }] } } 

OPA Gatekeeper (пример constraint)

apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sDenyHostPath metadata: name: deny-runtime-sockets spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: blockedPaths: - "/var/run/docker.sock" - "/run/containerd/containerd.sock" - "/var/run/crio/crio.sock" 

Усиление песочницы

• Включите профили seccomp, AppArmor/SELinux и флаг no-new-privileges по умолчанию см. рекомендации Docker .
• Минимизируйте Linux capabilities: оставляйте только необходимые для работы приложения.
• В Kubernetes используйте Pod Security уровня restricted и SecurityContext с запретом привилегированных контейнеров.

Удалённый Docker API — только с TLS и mTLS

Если по архитектуре нужен удалённый доступ к демону, применяйте TLS, проверку клиентских сертификатов и сетевую изоляцию (ACL, VPN, частные сегменты) официальный гайд .

Специальные инструменты (Portainer, Watchtower)

Для таких сервисов выделяйте отдельный узел/namespace, включайте TLS, ведите подробный аудит действий и ограничивайте эндпоинты API через прокси. Это не «рядовые» приложения и к ним нужен отдельный контроль.

CI/CD без проброса сокета

Сборка образов — главный источник соблазна «смонтировать сокет». Сегодня есть зрелые альтернативы.

• Kaniko — сборка в контейнере, артефакт сразу уходит в реестр; поддерживается кэширование слоёв.
• BuildKit — предоставляет производительность и кэш без необходимости управлять демоном на хосте; поддерживает rootless.
• Эфемерные раннеры — если нужен полноценный Docker, выполняйте сборку на отдельной VM и удаляйте её по завершении.
• Целостность цепочки поставки — подпись образов (Cosign/Sigstore), аттестации (SLSA) и политика приёма только подписанных артефактов.

Мониторинг и оповещения

Даже при строгих политиках стоит контролировать события, связанные с управлением контейнерами.

• Аномалии Docker/K8s: создание контейнеров вне релизных процедур, запуск с --privileged, появление hostPath на сокеты.
• Сетевые признаки: обращения к 2375/2376, неожиданный трафик к демону с нетипичных хостов.
• Аудит Kubernetes: фильтрация по verbs create/patch для Pod/DaemonSet/Deployment с проверкой volumes/hostPath.

Что делать, если «сокет уже внутри»

Контейнер с доступом к Docker API следует рассматривать как потенциальный мост на уровень узла. План реагирования:

1. Изоляция. Ограничьте сеть для Pod/контейнера, зафиксируйте состояние (снимки, логи).
2. Аудит действий API. Проверьте историю создания контейнеров, монтирования, изменения сетей и подключённые образы.
3. Проверка узла. Поиск неизвестных процессов/служб, новых пользователей, изменённых конфигураций, таймеров.
4. Ротация секретов. Ключи, токены, пароли — всё, до чего мог быть доступ, меняется в приоритетном порядке.
5. Восстановление из чистого состояния. Пересборка образов и переразвёртывание; «ремонт на месте» возможен, но рискован.
6. Постмортем. Почему проброс появился, почему его не поймали проверки, как предотвратить повторение.

Краткий чек-лист для продакшена

• Не монтируйте docker.sock и сокеты рантайма в приложения, которым это не критично.
• Если доступ необходим — только через прокси с белыми списками методов и учётной записью с минимальными правами.
• Используйте rootless Docker и/или userns-remap там, где возможно.
• В Kubernetes применяйте Pod Security (restricted), Kyverno/Gatekeeper, NetworkPolicy.
• Собирайте образы через Kaniko/BuildKit; для исключений — эфемерные раннеры.
• Включите аудит Docker/K8s и оповещения на опасные паттерны.
• Регулярно сканируйте IaC (Trivy/Checkov/KICS) и блокируйте PR с пробросом сокетов.

Частые вопросы

«У нас закрытый контур. Это действительно проблема?»

Да. Внутренний периметр снижает вероятность внешней атаки, но не исключает компрометацию учётных данных или уязвимость в приложении. Доступ к Docker API предоставляет слишком много полномочий, чтобы рассчитывать на «закрытую» сеть как основной барьер.

«Portainer/Watchtower без сокета не работают. Что делать?»

Выделить отдельный узел/namespace, ограничить эндпоинты API через прокси, включить TLS и детальный аудит. Это допустимая конфигурация при условии минимизации прав и постоянного контроля.

«SELinux/AppArmor решают проблему?»

Эти механизмы полезны и обязательны как часть слоёной защиты. Однако, имея доступ к Docker API, злоумышленник действует в рамках разрешённых интерфейсов демона. Политики на уровне платформы и ограничение API всё равно необходимы.

«Нужна разовая диагностика. Можно ненадолго?»

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

Итоги

Проброс docker.sock — это не «удобный компромисс», а канал прямого управления узлом. Хорошая новость в том, что существуют зрелые альтернативы: инструменты сборки без сокета, прокси над API с минимально достаточными правами, rootless-режим, user namespaces и политики на уровне платформы. Комбинация этих мер позволяет отказаться от опасной конфигурации или сделать её строго контролируемой в исключительных случаях. Это снижает вероятность побега из контейнера и упрощает расследование, если что-то идёт не по плану.