Защита и аудит Docker Engine

Краткое содержание

Эта статья объясняет архитектуру Docker, основные векторы атак, настройки для повышения безопасности демона и контейнеров, а также содержит практические контрольные списки, методологию аудита, план реагирования на компрометацию демона и тест-кейсы для приёмки. Полезно для DevOps, инженеров по безопасности и разработчиков.

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

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

Понятия в одну строку

• Docker daemon: фоновой сервис, управляющий контейнерами и образами.
• REST API: интерфейс управления демоном (UNIX socket или TCP).
• Rootless: запуск Docker без привилегий root, с пространством имён пользователей.
• Capabilities: гранулированные права ядра Linux для процессов.

Понимание архитектуры Docker

Docker состоит из трёх ключевых компонентов:

• Docker Engine daemon — фоновой процесс (обычно systemd unit), который управляет контейнерами, образами, сетью и томами.
• REST API — интерфейс, по которому клиентские инструменты отправляют команды демону. Обычно он слушает unix-сокет /var/run/docker.sock, но может быть открыт на TCP-порту.
• Клиентская утилита docker — CLI, который обращается к REST API демона.

Атаки могут быть направлены на любую из этих частей. Получив доступ к unix-сокету демона, злоумышленник получает эквивалент контроля над хостом, так как демон обычно работает от root.

Пример: docker client -> unix socket -> daemon -> управление контейнерами/файлами/устройствами хоста.

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

Вектор атаки: обзор

Основной вектор — компрометация Docker daemon. Контейнеры, имеющие доступ к /var/run/docker.sock, фактически получают права демона и могут:

• Поднимать новые контейнеры с host-монтажами.
• Монтировать файловые системы хоста в контейнер.
• Эскалировать до root уровня на хосте.

Другие векторы:

• Открытый TCP-порт Docker API без TLS/аутентификации.
• Неправильно настроенные capabilities и seccomp-профили.
• Отсутствие SELinux/AppArmor и других механизмов ядра.

Примеры атак: получение оболочки в контейнере -> монтирование / -> чтение /etc/shadow; использование capability SYS_ADMIN для побега из контейнера.

Защита сокета демона

Лучшее правило: доступ к /var/run/docker.sock должен быть предоставлен только root и доверенным сервисам.

Рекомендации:

• Не монтируйте /var/run/docker.sock внутрь контейнеров, если только это не строго необходимо и вы полностью доверяете образу.
• Для инструментов управления контейнерами используйте API-прокси или выделенные сервисы с ограниченной функциональностью.
• Ограничьте группу доступа к сокету (например, добавьте управляющие сервисы в группу docker только после оценки рисков).

Технический пример: проверьте права сокета

ls -l /var/run/docker.sock

Ожидаемый результат: сокет доступен только root или явно доверенной группе.

Если необходимо предоставить доступ программно, рассмотрите прокси, который реализует RBAC и аудиторские логи.

Защита TCP API

Не открывайте Docker API по TCP без защиты.

Практические шаги:

• Отключите опцию слушать на TCP, если она не нужна.
• Если необходимо, включите TLS и используйте клиентские сертификаты для аутентификации.
• Разделяйте сеть управления (management network) и рабочую сеть. Разрешайте трафик к API только с конкретных адресов.
• Контролируйте доступ сетевыми ACL/брандмауэрами и проверяйте правила iptables/ufw.

Пример включения TLS (упрощённо): генерируете CA, серверный и клиентские сертификаты и стартуете демон с параметрами –tlsverify –tlscacert=ca.pem –tlscert=server-cert.pem –tlskey=server-key.pem -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock

Важно: настройте ротацию сертификатов и храните ключи в безопасном хранилище.

Rootless режим

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

Преимущества:

• Меньший blast radius при компрометации.
• Уменьшение риска нарушения целостности хоста.

Ограничения и нюансы:

• Не все storage драйверы поддерживаются.
• Overlay сети и некоторые сетевые функции ограничены.
• Доступ к портам ниже 1024 может требовать дополнительных настроек.
• Требуется настройка под конкретный дистрибутив и внимательное тестирование.

Когда использовать:

• На multi-tenant средах с недоверенными пользователями.
• Когда требуются дополнительные гарантии безопасности для CI/CD раннеров.

Когда не подходит:

• Если ваша архитектура использует специфичные возможности ядра, которые не поддерживаются rootless режимом.

Команды для начала:

dockerd-rootless-setuptool.sh install

Или следуйте официальной документации для вашей ОС.

Ограничение общения между контейнерами

По умолчанию Docker разрешает коммуникацию между контейнерами через мост docker0. Это удобно, но увеличивает поверхность атаки.

Меры защиты:

• Запустите демон с флагом –icc=false чтобы отключить inter-container communication на уровне docker0.
• Используйте пользовательские bridge-сети или overlay-сети и контролируйте подключения с помощью сетевых политик (например, Calico, Cilium).
• Для простых сценариев используйте опцию –internal при создании сети, чтобы сделать её недоступной снаружи.

Пример команды для создания изолированной сети:

docker network create --internal --driver bridge restricted-net

Лучший подход — явно разрешать связь только между сервисами, которые должны взаимодействовать, а не разрешать всё по умолчанию.

Ограничение возможностей контейнера (Capabilities)

Ядро Linux предоставляет набор возможностей (capabilities), которые заменяют прежнюю модель полного root. Контейнерам следует давать минимально необходимые возможности.

Docker по умолчанию убирает часть возможностей, но часто этого недостаточно.

Практики:

• Полностью сбрасывайте capabilities и добавляйте только нужные:

docker run --cap-drop=ALL --cap-add=SYSLOG example-image:latest

• Используйте seccomp-профили для ограничения системных вызовов.
• Отключайте привилегированный режим (–privileged) — он даёт почти все права ядра и монтирует много устройств.

Как оценивать:

• Составьте список действий, которые контейнер должен выполнять (сеть, запись в лог, доступ к устройствам) и на основе этого определите минимальный набор capabilities.
• Применяйте правило «drop all, add only necessary».

Примеры опасных capabilities:

• SYS_ADMIN — часто приводит к возможностям побега из контейнера.
• SYS_MODULE — загрузка модулей ядра.

Используйте утилиты и справочники capabilities при оценке.

Seccomp и профиль по умолчанию

Seccomp позволяет ограничить системные вызовы, доступные процессам в контейнере. Docker поставляется с дефолтным seccomp профилем, но для критичных задач стоит создать собственный профиль.

Шаги:

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

Пример запуска контейнера с кастомным профилем:

docker run --security-opt seccomp=/path/to/seccomp.json example-image

AppArmor и SELinux

Используйте механизмы LSM (Linux Security Modules): SELinux или AppArmor, в зависимости от дистрибутива.

SELinux:

• В RHEL/CentOS/Fedora включать полезно: docker daemon поддерживает опцию –selinux-enabled.
• SELinux метки (labels) помогают ограничить доступ контейнера к файловой системе хоста.

AppArmor:

• На Debian/Ubuntu используйте AppArmor профили для контейнеров.
• AppArmor позволяет задать тонкие ограничения на доступ к системным ресурсам.

Лучшие практики:

• Не отключайте LSM в продакшене.
• Тестируйте политика в режиме complain/audit, прежде чем переводить в enforce.

Хранение секретов и управление конфигурацией

Не храните секреты в образах или в явном виде в переменных окружения. Рассмотрите:

• Docker secrets (в Docker Swarm) или провайдеры секретов в Kubernetes.
• Интеграцию с HashiCorp Vault, AWS Secrets Manager или другими KMS.
• Минимизацию объёма конфиденциальной информации, доступной в контейнере.

Общий принцип: секрет доступен только сервису, который его использует, и только в момент использования.

Обновления и поддержка ядра

Контейнеры используют ядро хоста — обновление ядра критично.

Рекомендации:

• Регулярно обновляйте хост и Docker Engine до поддерживаемых версий.
• Поддерживайте цикл патчей: тестирование в staging, затем rolling deploy на prod.
• Мониторьте рассылки безопасности и CVE для Docker, runc, containerd и драйверов хранения.

Стратегия распределения нагрузки и хостовой изоляции

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

Методология аудита Docker — мини-метод

1. Идентификация: перечислите все хосты с запущенным Docker.
2. Возможности доступа: проверьте права на /var/run/docker.sock, открытые TCP-порты, firewall.
3. Конфигурация демона: проверьте systemd unit или daemon.json на небезопасные флаги.
4. Образы: проверьте происхождение образов, наличие уязвимостей.
5. Контейнеры в работе: проанализируйте запущенные контейнеры на привилегии и монтирования.
6. Логи и мониторинг: включите аудит доступа к демону и системные логи.
7. Тестирование: проведите pentest/эмулируйте компрометацию одного контейнера, чтобы оценить blast radius.

Чеклист для быстрой проверки (SOP)

• /var/run/docker.sock доступен только root или доверенной группе.
• Docker API по TCP либо выключен, либо защищён TLS и ACL.
• Демон не запущен с –privileged и не использует опасные флаги.
• Контейнеры не монтируют критичные каталоги хоста (/, /etc, /var).
• capabilities сброшены с применением –cap-drop и –cap-add.
• Seccomp профиль активен и протестирован.
• SELinux/AppArmor включены и в режиме enforce для production.
• Образы проверены на уязвимости и подписаны/верифицированы.
• Резервное копирование данных и план восстановления проверены.

Ролевые контрольные списки

DevOps/Инженер по развертыванию:

• Автоматизировать конфигурацию демона (systemd unit, daemon.json).
• Настроить TLS для Docker API и управление сертификатами.
• Интегрировать CI/CD с проверкой образов и сканированием уязвимостей.

Инженер по безопасности:

• Провести аудит прав на сокет и сетевые правила.
• Настроить правила SELinux/AppArmor и seccomp-профили.
• Провести сценарии инцидентов и тестирования на проникновение.

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

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

План реагирования на компрометацию демона (инцидентный рукопис)

1. Изолировать хост: блокировать сетевой доступ к Docker API, выключить интерфейсы, если нужно.
2. Снять снапшоты/копии дисков и логов для форензики.
3. Остановить все контейнеры и просканировать их содержимое на компрометацию.
4. Проанализировать логи Docker и системные логи для вектора атаки.
5. Принять решение о перезапуске хоста/восстановлении из чистых образов.
6. Сменить сертификаты и креденшалы, которые могли быть скомпрометированы.
7. Провести пост-мортем и обновить политики доступа и процессы.

Важно: при подозрении на широкую компрометацию избегайте простого reboot без снятия доказательств.

Тестовые случаи и критерии приёмки

Тест 1: Доступ к /var/run/docker.sock

• Условие: пользователь non-root не в группе docker.
• Ожидаемый результат: попытка доступа к socket завершается отказом.

Тест 2: REST API по TCP

• Условие: Docker API слушает на порту 2376.
• Ожидаемый результат: соединение защищено TLS; только клиенты с валидными сертификатами проходят.

Тест 3: Ограничение коммуникации

• Условие: демон запущен с –icc=false
• Ожидаемый результат: контейнер A не может подключиться к контейнеру B без явного моста или явной сети.

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

• Все тесты должны пройти в staging и prod (с учётом падения функционала), и результаты должны быть задокументированы.

Когда эти меры не сработают / ограничения

• Если злоумышленник получил root на хосте вне Docker (через другую уязвимость), ограничения внутри Docker будут бесполезны.
• Rootless не защитит от уязвимостей в ядре или в механизмах виртуализации гипервизора.
• Seccomp и LSM не заменяют необходимость в надёжных образах и корректной сетевой сегментации.

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

• Перед переводом в rootless режим проверьте поддержку storage драйвера и сетевых функций в вашей версии ОС.
• Тестируйте политики SELinux/AppArmor на staging и используйте audit-режим, чтобы избежать неожиданного отказа сервисов.

Приватность и соответствие требованиям

• Контейнеры не должны иметь доступ к PII/секретам без необходимости. Храните журналы и данные в зашифрованных хранилищах.
• Для GDPR: документируйте, какие сервисы обрабатывают персональные данные и ограничьте доступ на уровне сети и ролей.

Пример конфигурации systemd для демона с TLS (вариант)

[Service]
ExecStart=/usr/bin/dockerd --tlsverify --tlscacert=/etc/docker/ca.pem --tlscert=/etc/docker/server-cert.pem --tlskey=/etc/docker/server-key.pem -H fd://

Разместите сертификаты с правами 600 и владельцем root.

Полезные команды для аудита

• Проверить версии:

docker version
uname -a

• Проверить запущенные контейнеры и права:

docker ps --format '{{.ID}} {{.Names}} {{.Image}}'
docker inspect --format='{{json .HostConfig}}' 

• Проверить права сокета:

stat -c '%a %U %G %n' /var/run/docker.sock

Ресурсы и стандартные практики

• Всегда тестируйте изменения безопасности в staging среде и имейте план отката.
• Автоматизируйте обновления и сканирование образов.
• Храните политики и профили в системе контроля версий.

Часто задаваемые вопросы

Нужно ли вообще использовать rootless режим?

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

Можно ли безопасно монтировать /var/run/docker.sock в контейнер?

Рекомендуется избегать прямого монтирования сокета. Если это неизбежно (например, для инструментов управления), используйте доверенные образы, ограничьте возможности контейнера и применяйте прокси с RBAC.

Как быстро проверить, открыто ли API по TCP?

Выполните netstat/ss или проверьте systemd unit демона на наличие -H tcp://… Также попытка подключения curl к порту 2375/2376 покажет ответ.

Резюме

• Защита Docker начинается с контроля доступа к демону и сокету.
• Rootless режим снижает риск, но требует тестирования и может ограничить функционал.
• Ограничивайте capabilities, применяйте seccomp и LSM (SELinux/AppArmor).
• Используйте сеть и политики, чтобы предотвратить ненужное взаимодействие между контейнерами.
• Внедрите процесс аудита, проверьте образы и подготовьте план реагирования на инциденты.

Важно: безопасность — это слой ответственности, который включает разработчиков, DevOps и инженеров по безопасности.

Ключевые действия (быстрый план на 30 дней):

1. Проинвентаризовать хосты с Docker.
2. Закрыть доступ к /var/run/docker.sock там, где возможно.
3. Настроить мониторинг и аудит логов Docker.
4. Внедрить сканирование образов в CI.
5. Протестировать перевод ключевых рабочих нагрузок в rootless (если применимо).