Практический разбор · Docker
Docker Rootless mode: проверьте запуск daemon без root
Rootless mode запускает Docker daemon и контейнеры внутри user namespace от непривилегированного пользователя. Проверьте требования, активный context и ограничения совместимости, не выдавая rootful socket ради удобства.
Кому нужно проверить
Администраторам Linux-хостов и команд CI, которым не требуется управление Docker от root. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Rootful daemon и доступ к его socket имеют высокие привилегии. Rootless mode запускает daemon и контейнеры внутри user namespace и не использует SETUID-бинарники, кроме необходимых средств сопоставления UID/GID. При этом не все функции и драйверы совместимы, а доступ к rootless socket всё равно должен быть ограничен.
Затронутые версии
Руководство для Linux-хостов с Docker Engine, где daemon и контейнеры можно запускать без root. Требуются newuidmap, newgidmap и диапазоны subordinate UID/GID; отдельные сетевые, storage и workload-возможности могут иметь ограничения.
Исправленные версии
Это не исправление CVE и не универсальная замена rootful режиму. Установите поддерживаемую версию Docker, настройте Rootless mode по документации и подтвердите, что фактический context указывает на rootless daemon.
Что сделать
- 1Опишите workload и функции Docker, которые действительно нужны: сеть, storage, privileged-контейнеры, публикация портов и интеграции CI. Отдельно зафиксируйте ограничения, которые могут повлиять на доступность.
- 2Проверьте наличие newuidmap и newgidmap и минимум 65 536 subordinate UID/GID в /etc/subuid и /etc/subgid для выбранного пользователя. Не копируйте содержимое этих файлов в публичный отчёт.
- 3Установите Rootless mode штатным скриптом или пакетами Docker от непривилегированного пользователя и создайте отдельный CLI context. Не оставляйте параллельно работающий rootful socket без необходимости.
- 4Проверьте, что systemd user service запущен от нужного пользователя, а DOCKER_HOST и context не возвращают CLI к rootful daemon.
- 5На staging проверьте сборку, запуск, сеть, volumes, restart policy и требуемые health checks. Сравните поведение с прежним режимом и не расширяйте права из-за одной несовместимой функции без оценки.
- 6Переведите workload поэтапно и наблюдайте журналы daemon, состояние контейнеров и использование ресурсов. Для отката заранее сохраните прежний context и конфигурацию, но не удаляйте rootless setup до подтверждения стабильности.
- 7Регулярно проверяйте, что контейнеры действительно работают через rootless daemon, а пользователи и CI не получили доступ к rootful socket.
Примеры конфигурации и проверки
docker context show
docker info --format '{{json .SecurityOptions}}'Запускайте от пользователя, который должен управлять rootless Docker. Команды читают выбранный context и Security Options, не меняют daemon и не раскрывают содержимое контейнеров. Вывод может содержать сведения о конфигурации хоста, поэтому не публикуйте его целиком. Наличие слова rootless следует сопоставить с context и фактическим socket. Откат не нужен.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.