Docker Bench: аудит безопасности Docker-хоста

Быстрые ссылки

Running the Script
Understanding the Report
Container Images
Container Runtime
Docker Swarm
Addressing Common Issues
Customizing Report Output
Conclusion

Иллюстрация: иконка и общий вид Docker Bench for Security

Важно: Docker удобен, но может представлять риск для безопасности. Особенно это касается production-хостов. Docker Bench — это автоматизированный скрипт от сообщества Docker, который помогает быстро найти проблемные места в настройке Docker Engine.

Что это делает и когда запускать

Docker Bench for Security автоматически проверяет конфигурацию хоста, демона и контейнеров. Скрипт выполняет более 200 проверок и формирует отчёт с пометками PASS/WARN/INFO. Запускайте его при развертывании хоста, после изменений в конфигурации демона и по расписанию (например, как часть ежемесячного аудита).

Примечание: Docker Bench не заменяет сканеры уязвимостей образов и политик CI/CD — используйте его в сочетании с такими инструментами, как Trivy или Clair.

Запуск скрипта

Следуйте этим шагам для безопасного запуска Docker Bench:

Клонируйте репозиторий и проверьте код, если хотите.

git clone https://github.com/docker/docker-bench-security.git

Перейдите в каталог и выполните сканирование от root (некоторые проверки требуют привилегий):

cd docker-bench-security
sudo sh docker-bench-security.sh

Результат появится в терминале. Скрипт занимает от нескольких секунд до минуты и дольше, если много контейнеров.

Важно: запуск в CI/automation без sudo ограничит часть проверок. Если используете в CI, отдавайте отчёт в файл опцией -l и анализируйте его другим шагом пайплайна.

Как читать отчёт

Отчёт цветовой и структурированный:

Синие строки INFO — вход в секции и вспомогательная информация.
Зелёные PASS — проверка пройдена.
Красные WARN — потенциальная уязвимость или несоответствие.

Скриншот отчёта Docker Bench for Security в терминале

Docker Bench выполняет более 200 проверок; некоторые ключевые группы тестов ниже.

Конфигурация хоста

Проверяет аудит файлов, правильность прав доступа, наличие выделенного раздела для /var/lib/docker и актуальность версии Docker.

Что смотреть в отчёте:

Наличие записей аудита для критичных директорий.
Права и владельца для /var/lib/docker и исполняемых файлов Docker.

Конфигурация демона

Проверки на предмет открытого сокета, небезопасных реестров и настройки сетевого взаимодействия между контейнерами (bridge). Скрипт также проверяет права на файлы конфигурации демона и владельца файловой системы Docker.

Замечание: файл системы Docker должен принадлежать root:root, а файлы конфигурации — иметь ограниченные права доступа (в идеале 644 или строже для некоторых файлов).

Образы контейнеров

Docker Bench базово анализирует Dockerfile известных образов: проверяет наличие непользовательских пользователей, инструкций HEALTHCHECK и использование Content Trust. Скрипт также напоминает про базовые меры: использовать проверенные образы, вырезать ненужные пакеты и своевременно применять обновления.

Runtime контейнеров

Runtime-проверки (более 30 тестов) смотрят на SELinux/AppArmor, корректные монтирования файловых систем, ограничения CPU/памяти, отсутствие привилегированных контейнеров и монтирования Docker-сокета внутрь контейнеров.

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

Привилегированные контейнеры и монтирование сокета docker.sock позволяют атакующему получить контроль над хостом.
Отсутствие лимитов ресурсов может привести к OOM и отказу сервисов.

Docker Swarm

Отдельная секция для Swarm — проверяет секции secret, ротацию сертификатов и шифрование overlay-сетей. Скрипт выдаст WARN, если включён Swarm, но режим не используется. В таком случае рекомендуется выключить Swarm:

docker swarm leave --force

Частые проблемы и как их решать

Ниже — практические шаги по устранению часто встречающихся предупреждений.

Включение аудита для файлов Docker

Для ведения аудита установите auditd и добавьте правила аудита в /etc/audit/audit.rules. Пример правил:

-w /etc/default/docker -p wa
-w /etc/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /usr/bin/docker -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa
-w /var/lib/docker -p wa

Параметр -p wa регистрирует записи при записи и изменении атрибутов. После изменения перезапустите auditd:

sudo systemctl restart auditd

Важно: правила аудита зависят от дистрибутива и структуры файловой системы — адаптируйте список директорий под вашу среду.

Усиление настроек демона

Добавьте в /etc/docker/daemon.json следующие параметры, чтобы закрыть типовые замечания:

{  
    "icc": false,  
    "live-restore": true,  
    "no-new-privileges": true,  
    "userland-proxy": false,  
    "userns-remap": "default"  
}

Краткие пояснения:

icc: false — запрещает взаимодействие контейнеров по дефолтной bridge-сети.
live-restore: true — позволяет контейнерам оставаться запущенными при перезапуске демона.
no-new-privileges: true — блокирует возможность повышения привилегий внутри контейнера.
userland-proxy: false — использует iptables для проброса портов (меньше пользовательского кода).
userns-remap: default — включает remap пользователей, чтобы root внутри контейнера отображался на непривилегированного пользователя хоста.

Примечание: некоторые приложения ожидают определённого поведения сети или прав; протестируйте изменения в staging перед применением в production.

Настройка вывода отчёта

Опции скрипта полезны для CI и автоматизации:

-b — отключить цвета (для CI).
-p — не выводить рекомендации по ремедиации.
-l report.txt — записать результат в файл.
-c check_5.1,check_5.2 — запустить только указанные проверки.
-e check_5.1,check_5.2 — исключить указанные проверки.

Совет: создайте shell-алиас или обёртку для типичных комбинаций флагов, используемых в вашей среде.

Роль-based чеклисты (кто что делает)

Ниже — разбивка задач по ролям, чтобы быстрее реагировать на отчёт.

Администратор хоста:

Установить и настроить auditd.
Проверить права на файлы Docker.
Обновить systemd-юниты и перезапустить сервисы.

DevOps инженер:

Внедрить daemon.json с базовыми мерами жёсткости.
Настроить userns-remap и протестировать работу приложений.
Добавить проверку Docker Bench в CI или cron.

Разработчик:

Использовать непользовательского пользователя в Dockerfile.
Добавлять HEALTHCHECK и минимизировать пакеты.
Периодически пересобирать образы с актуальными патчами.

Безопасник:

Анализировать WARN и классифицировать риски.
Совместно с DevOps вырабатывать план ремедиации.
Сопоставлять результаты с политиками безопасности компании.

Playbook — как исправлять критичные WARN

Классификация — пометьте WARN как High/Medium/Low по влиянию. High — привилегированные контейнеры, docker.sock в контейнере, незашифрованные секреты.
Блокировка распространения — если обнаружен привилегированный контейнер с доступом к сокету, немедленно ограничьте доступ и создайте инспекцию образа.
Ремедиация — внесите изменения в daemon.json, пересоберите образ без SSH и лишних пакетов, добавьте ресурсоограничения.
Валидация — повторно запустите Docker Bench и добавьте дополнительный тест в CI.
Документация — зафиксируйте принятые решения и критерии приёмки.

Критерии приёмки

PASS по ключевым проверкам демона: отсутствие открытых сокетов, наличие no-new-privileges, userns-remap.
Нет привилегированных контейнеров и монтирования docker.sock в production.
Наличие правил аудита для критичных директорий.

Ментальные модели и эвристики

Least Privilege: давайте контейнерам минимально необходимые права.
Immutable Infrastructure: по возможности пересобирайте образы вместо внесения изменений в рантайме.
Defence in Depth: сочетайте контроль доступа, аудит и обновления образов.

Примеры альтернативных подходов

Вместо userns-remap можно применять Podman/CRI-совместимые рантаймы, которые изначально менее привилегированы.
Для сетевой изоляции используйте сетевые плагины CNI, которые предоставляют дополнительные политики (Calico, Cilium).

Тест-кейсы и приёмка

Ниже — примеры автоматических тестов, которые можно добавить в CI:

После развертывания хоста запустить Docker Bench; сборка должна вернуть code 0 при отсутствии критичных WARN.
Тест на отсутствие docker.sock в контейнерах: поиск монтирований вида /var/run/docker.sock.
Тест на отсутствие привилегированных контейнеров: docker ps –filter “status=running” –format ‘{{.ID}}’ | xargs docker inspect –format ‘{{.HostConfig.Privileged}}’ должен вернуть false для всех.

Критерии приёмки: все автоматические тесты должны проходить в staging перед promotion в production.

Решение спорных случаев и контрпримеры

Иногда предупреждение можно игнорировать, если есть допустимые причины. Например, в разработке вы можете запускать контейнеры с повышенными правами для отладки. Однако для production такие исключения должны быть документированы, одобрены и иметь компенсирующие меры (например, изолированный сетевой сегмент).

Матрица рисков и смягчения

Привилегированные контейнеры — Риск высокий. Смягчение: убрать привилегии, использовать capabilities.
Монтирование docker.sock — Риск высокий. Смягчение: использовать API прокси с ограничениями, не монтировать сокет.
Неограниченные ресурсы — Риск средний. Смягчение: лимиты CPU/памяти.
Отсутствие аудита — Риск средний. Смягчение: включить auditd и централизовать логи.

Совместимость и миграция

Настройка userns-remap может требовать пересборки и перезапуска контейнеров. Тестируйте на staging.
Не все дистрибутивы используют одинаковые пути для systemd-юнитов; адаптируйте правила аудита.

Безопасное использование Swarm

Шифруйте overlay-сети и включите ротацию сертификатов.
Если Swarm не используется — выключите его.

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

Что такое Docker Bench?

Docker Bench — это набор скриптов для автоматического аудита конфигурации Docker Engine и рантайма контейнеров по ряду рекомендаций сообщества Docker.

Нужно ли запускать скрипт на каждом хосте?

Да. Конфигурация и состояние контейнеров индивидуальны для каждого хоста. Рекомендуется запустить на каждом production-хосте.

Заменяет ли Docker Bench сканеры уязвимостей образов?

Нет. Docker Bench фокусируется на конфигурации и рантайме. Для анализа уязвимостей образов используйте Trivy, Clair или подобные инструменты.

Заключение

Docker Bench for Security — быстрый и бесплатный способ получить обзор безопасности Docker-хоста. Это не панацея, но важный элемент защищённого процесса. Запускайте скрипт регулярно, фиксируйте WARN, применяйте базовые настройки жесткости демона и интегрируйте проверки в CI/CD.

Важно: не все проверки обязательны для development-среды. Оценивайте релевантность каждой проверки с точки зрения контекста вашей инфраструктуры.

Быстрый чек-лист для первого запуска

Клонировать репозиторий docker-bench-security.
Запустить с sudo и сохранить отчёт в файл.
Классифицировать WARN по приоритету.
Применить корректировки в daemon.json и правила аудита.
Повторно запустить скрипт и зафиксировать результат.

Дополнительные ресурсы

Официальный репозиторий: https://github.com/docker/docker-bench-security
Сканеры образов: Trivy, Clair

Факты:

Docker Bench выполняет более 200 проверок.
Раздел Runtime включает более 30 тестов.

Примечание: список проверок и рекомендации могут меняться вместе с развитием официального проекта — проверяйте актуальную версию на GitHub.

Как использовать Docker Bench for Security для аудита безопасности Docker-хоста