Docker socket

Почему опасно его монтировать

Многие инструменты просят смонтировать сокет в контейнер. Это даёт контейнеру возможность запускать новые контейнеры, в том числе такие, что монтируют файловую систему хоста. OWASP также отмечает, что монтирование сокета только для чтения не делает API Docker доступным только для чтения.

Как обращаться с ним безопасно

Не отдавайте сокет контейнерам, где это возможно, ограничьте группу docker доверенными администраторами, никогда не открывайте демон по TCP без TLS и рассмотрите rootless-режим. Подробности есть в нашем руководстве по безопасности Docker-хоста.

Как проверить, кто может обратиться к сокету

В справочнике dockerd сказано, что по умолчанию демон создаёт /var/run/docker.sock, и пользоваться им могут только root и члены группы docker. Аудит доступа сводится к трём вопросам, на каждый из которых отвечает одна команда:

ls -l /var/run/docker.sock
getent group docker
docker ps --filter volume=/var/run/docker.sock --format "table {{.ID}}\t{{.Names}}"

Первая показывает владельца и группу файла сокета. Если группа не docker или права шире ожидаемых, выясните причину. Вторая выводит всех членов группы, а это должны быть люди, которым вы доверили бы root, ведь Docker сообщает, что группа даёт привилегии уровня root. Использование getent вместо чтения /etc/group захватывает и записи из служб каталогов. Третья применяет документированный фильтр volume команды docker ps, чтобы показать запущенные контейнеры, в которые смонтирован сокет.

Эта команда не видит остановленные контейнеры и ещё не запущенные службы, поэтому дополнительно поищите в конфигурации определения, которые монтируют сокет:

grep -rn "docker.sock" /opt /srv --include="*.yml" --include="*.yaml"

Подставьте пути, где лежат ваши compose-файлы. Для каждого найденного случая запишите, зачем нужен сокет, и уберите те, которые никто не может обосновать. Принцип, на котором основана эта проверка, описан в статье про минимальные привилегии.

Прокси сокета, rootless-режим и удалённое управление

Когда инструменту действительно нужен API, сузьте то, что он может делать. Проект Tecnativa docker-socket-proxy ставит перед сокетом фильтр на основе HAProxy и отвечает на запрещённые запросы кодом HTTP 403. Согласно его README, по умолчанию разрешены только разделы EVENTS, PING и VERSION, а параметр POST по умолчанию выключен, из-за чего API остаётся доступным только для чтения. Нужные инструменту разделы включаются переменными окружения, например CONTAINERS=1. В README также предупреждают: никогда не открывайте порт прокси в публичную сеть и держите его в сети Docker, где есть только он и использующий его инструмент. Учтите, что сам контейнер прокси монтирует настоящий сокет, поэтому он сужает доступ, а не устраняет риск.

Другой подход состоит в уменьшении привилегий самого демона. В rootless-режиме демон работает от обычного пользователя, и сокет находится в его каталоге времени выполнения, например unix:///run/user/1000/docker.sock в примере Docker. Docker описывает этот режим как способ снизить последствия возможных уязвимостей демона и среды выполнения контейнеров.

Для удалённого управления предпочитайте SSH-соединение, а не TCP-порт. В документации по защите доступа Docker показан контекст, созданный с адресом host=ssh://, и отмечено, что у SSH-пользователя должны быть права на сокет на удалённой машине, а значит эта учётная запись по-прежнему эквивалентна root. Защищайте её ключи соответственно, используя руководство по укреплению SSH.

Связанные термины: Принцип минимальных привилегий, UID 0, Firewall, UFW, Docker socket proxy (прокси сокета Docker).