Аудит безопасности контейнерной среды в 2026 году требует новых подходов. Экосистема Docker кардинально изменилась за последние 18 месяцев, и классические проверки образов и хостов теперь недостаточны. Появление Docker AI stack для production-развертываний GenAI-нагрузок создает дополнительные векторы атак через инструменты Docker Model Runner (DMR), MCP Gateway и Docker Sandboxes. Это руководство предоставляет комплексный чек-лист, который учитывает как традиционные риски, так и новые компоненты. Вы получите пошаговую методику с конкретными командами для сканирования образов, проверки конфигураций хостов и кластеров Kubernetes, а также рекомендации по аудиту AI-стека.
Почему стандартные чек-листы устарели? Контекст безопасности 2026 года
Экосистема Docker и Kubernetes развивается стремительно. За последние два года появились новые стандарты развертывания, инструменты и, как следствие, новые угрозы. Классические чек-листы, основанные на CIS Benchmarks 2023-2024 годов, часто не учитывают эти изменения. Основное отличие современного контекста - интеграция AI-инструментов в production-среды. Docker AI stack, включающий Docker Model Runner для локального запуска LLM, MCP Gateway для взаимодействия с моделями через Model Context Protocol и Docker Sandboxes для изоляции недоверенных workload-ов, стал стандартом для многих проектов. Аудит безопасности теперь должен охватывать конфигурацию этих компонентов наравне с проверкой базовых образов и демона.
Docker AI stack: на что обратить внимание в первую очередь?
При аудите среды, использующей Docker AI stack, сосредоточитесь на четырех ключевых областях.
1. Docker Model Runner (DMR). Проверьте источники и целостность LLM-образов. Убедитесь, что модели загружаются из доверенных реестров или имеют проверенные цифровые signatures. Контролируйте ресурсы (GPU, память), выделенные для процессов запуска моделей, чтобы предотвратить истощение ресурсов хоста. Убедитесь в изоляции этих процессов.
2. MCP Gateway. Аудите конфигурацию шлюза. Проверьте правила аутентификации и авторизации запросов, поступающих через Model Context Protocol. Убедитесь, что доступ к моделям ограничен только необходимым сервисам или пользователям.
3. Docker Sandboxes (микро-VM). Убедитесь, что эта функция активирована для изоляции недоверенных workload-ов, особенно тех, которые обрабатывают конфиденциальные данные или взаимодействуют с внешними AI-сервисами. Проверьте настройки политик безопасности sandbox.
4. Docker Agents для multi-agent систем. Если в вашей среде используются агенты для оркестрации сложных AI-процессов, проверьте сетевое взаимодействие между ними. Убедитесь, что права доступа каждого агента строго ограничены его функцией, а механизмы управления секретами (токены, ключи API) защищены.
Игнорирование этих новых компонентов создает риски утечки данных, несанкционированного доступа к моделям и компрометации всей AI-инфраструктуры. Классические проверки остаются обязательными, но теперь они лишь часть картины.
Фундамент: аудит безопасности Docker-образов и реестров
Уязвимый образ - уязвимый контейнер. Проверка образов на наличие известных CVE остается первым и самым важным шагом. Для этого используют инструменты сканирования, такие как Trivy и Clair. Trivy предлагает простоту и скорость, Clair - детальность и глубокую интеграцию в пайплайны.
Пошаговое сканирование с Trivy: команды и разбор вывода
Trivy позволяет быстро проверить локальные образы, файловые системы и реестры. После установки (например, через apt install trivy или brew install trivy) выполните базовые команды.
Для сканирования локального образа:trivy image your-image:tag
Для сканирования текущей директории (например, Dockerfile):trivy fs .
Для сканирования удаленного реестра:trivy registry your-registry.com/your-image
Пример вывода Trivy показывает таблицу с полями: CVE ID, Severity (CRITICAL, HIGH, MEDIUM, LOW), Library (например, libc6), Fixed Version. Для интеграции с другими системами используйте форматы JSON или SARIF:trivy image --format json your-image:tag
Для сканирования приватного реестра добавьте флаги авторизации:trivy registry --username user --password pass your-private-registry.com/image
Найденные критические уязвимости требуют немедленного действия: патчинг базового образа или его полная замену на более безопасную версию.
Глубокая проверка с Clair и интеграция в пайплайн
Clair предоставляет более мощный анализ, особенно для интеграции в CI/CD. Его архитектура состоит из индексатора, который анализирует образы, и матчера, который сравнивает найденные пакеты с базой уязвимостей.
Для быстрого старта используйте docker-compose с официальной конфигурацией. После запуска отправьте манифест образа на анализ через API Clair. Настройте webhook-уведомления, чтобы получать алерты о критических уязвимостей прямо в Slack или Telegram.
В GitLab CI или GitHub Actions интеграция выглядит как дополнительный шаг в пайплайне после сборки образ. Пример для GitHub Actions:
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- name: Scan image with Clair
uses: quay/clair-action@v4
with:
image-name: ${{ env.IMAGE_NAME }}Это автоматизирует проверку и блокирует развертывание образов с высокорисковыми уязвимостями.
Аудит хоста Docker и конфигурации демона
Безопасность платформы Docker на уровне ОС определяет общую устойчивость среды. CIS Docker Benchmark предоставляет стандарт для минимизации поверхности атаки. Проверка включает анализ конфигурации демона, прав доступа к файлам и сокетам, логирования и сетевых настроек.
Разбор критичных параметров daemon.json с точки зрения CIS
Файл /etc/docker/daemon.json содержит ключевые настройки безопасности. Проверьте следующие параметры.
userns-remap. Эта настройка обеспечивает изоляцию пользовательских пространств имен, предотвращая эскалацию прав из контейнера на хост. Убедитесь, что она активна:"userns-remap": "default"
log-driver и log-opts. Гарантированный сбор логов необходим для аудита и реагирования на инциденты. Используйте надежный драйвер, например json-file или syslog, и установьте максимальный размер файла:"log-driver": "json-file",
"log-opts": {"max-size": "10m", "max-file": "3"}
live-restore. Позволяет демону Docker перезапускаться без остановки работающих контейнеров, повышая устойчивость."live-restore": true
userland-proxy. Отключение этого параметра повышает производительность и снижает сложность сетевого стека."userland-proxy": false
icc=false. Отключает межконтейнерную коммуникацию по умолчанию, требуя явного определения связей через сети."icc": false
TLS настройки. Для защищенного удаленного доступа к Docker API убедитесь, что используются TLS и сертификаты, а недоверенные соединения запрещены.
Проверьте также версии Docker и ядра ОС. Устаревшие версии содержат незакрытые уязвимости.
Автоматизация проверок: скрипты и Docker Bench for Security
Инструмент Docker Bench for Security автоматизирует проверку по CIS Benchmark. Запустите его одним командой:
docker run -it --net host --pid host --userns host --cap-add audit_control \
-v /etc:/etc:ro -v /usr/bin/containerd:/usr/bin/containerd:ro \
-v /usr/bin/runc:/usr/bin/runc:ro -v /usr/lib/systemd:/usr/lib/systemd:ro \
-v /var/lib:/var/lib:ro -v /var/run/docker.sock:/var/run/docker.sock:ro \
--rm docker/docker-bench-securityИнструмент проверяет сотни пунктов и выводит результат с маркировкой [PASS], [WARN] или [INFO]. Для регулярного аудита создайте простой Bash-скрипт, который проверяет ключевые параметры, например наличие icc=false или правильные права на сокет /var/run/docker.sock (должен быть 660, группа docker).
Этот подход экономит время и дает уверенность в полноте проверки. Для комплексного аудита всей инфраструктуры, включая сетевые сервисы и базы данных, используйте готовый план проверки, который охватывает все ключевые компоненты.
Глубокий аудит Kubernetes-кластера: от Pod Security до сетевых политик
Аудит кластера Kubernetes требует системного взгляда на иерархию безопасности: кластер, ноды, поды. Проверка включает конфигурацию kubelet и API-сервера, анализ RBAC, управление секретами, сетевую изоляцию и применение Pod Security Standards.
Аудит RBAC: находим избыточные права и сервисные аккаунты
Избыточные права - частый источник компрометации кластера. Используйте команды kubectl для анализа.
Выведите все привязки ролей в кластере:kubectl get clusterrolebindings -o widekubectl get rolebindings --all-namespaces
Проверьте права конкретного ServiceAccount:kubectl auth can-i --list --as=system:serviceaccount:default:my-service-account
Поищите привязки к опасным ClusterRole, например cluster-admin. Убедитесь, что они ограничены минимальным количеством аккаунтов. Проверьте, что автоматическое создание токенов для сервисных аккаунтов отключено (рекомендуется использовать механизмы типа TokenRequest). Принцип наименьших привилегий (Least Privilege) должен применяться строго.
Проверка сетевой безопасности: Network Policies и контроль трафика
Сетевая изоляция между неймспейсами и подами должна быть активной. Проверьте, что CNI-плагин поддерживает Network Policies (например, Calico, Cilium). Выведите все политики:kubectl get networkpolicies --all-namespaces
Анализируйте типичные ошибки: отсутствие podSelector, разрешение всего трафика (пустые правила from/to). Для тестирования создайте тестовые пода и проверьте доступность с помощью curl или nc внутри контейнера.
Пример базовой политики, которая запрещает весь трафик по умолчанию и разрешает только явно указанный:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
- EgressПосле применения такой политики все связи должны быть описаны отдельно.
Мониторинг и аудит активности: куда смотреть в первую очередь?
Для обнаружения уже произошедших или текущих инцидентах настроите аудит API-сервера Kubernetes. Audit policy определяет, какие события (create, update, delete) и для каких ресурсов (pods, secrets, roles) записываются в лог.
Ключевые события для мониторинга: создание подов с привилегированными флагами, изменение RBAC-объектов, доступ к секретам. Анализируйте логи kube-apiserver и kubelet. Для отслеживания в реальном времени используйте:kubectl get events --watch
Интегрируйте эти логи в SIEM-системы через Fluentd или Elasticsearch для централизованного анализа и алертов. Для комплексного подхода к аудиту, включающего проверку соответствия и имитацию атаки, рассмотрите методологии Red Team и Blue Team.
Готовый чек-лист для регулярного аудита безопасности (2026)
Этот чек-лист объединяет все проверки из статьи в структурированную таблицу. Используйте его для регулярного аудита вашей контейнерной среды. Каждая проверка включает команду или метод, критерий успеха и уровень критичности.
Чек-лист в формате таблицы: категория, проверка, команда, статус
| Категория | Проверка | Команда / Метод | Критичность |
|---|---|---|---|
| Образы и реестры | Сканирование всех образов в реестре на критические уязвимости | trivy registry your-registry |
High |
| Образы и реестры | Интеграция сканирования в CI/CD пайплайн | Настройка шага с Clair или Trivy в GitHub Actions/GitLab CI | Medium |
| Хост Docker | Проверка конфигурации демона (daemon.json) | Анализ файла /etc/docker/daemon.json на наличие icc=false, userns-remap, live-restore | High |
| Хост Docker | Автоматизированный аудит по CIS Benchmark | Запуск Docker Bench for Security | Medium |
| Kubernetes RBAC | Поиск избыточных привязок ролей | kubectl get clusterrolebindings -o wide | grep cluster-admin |
High |
| Kubernetes Сеть | Проверка применения Network Policies | kubectl get networkpolicies --all-namespaces |
High |
| Kubernetes Секреты | Проверка шифрования секретов на rest (etcd) | Наличие EncryptionConfiguration в kube-apiserver | Medium |
| Docker AI Stack | Аудит конфигурации Docker Model Runner | Проверка источников LLM-образов, контроля ресурсов (GPU/память) | High |
| Docker AI Stack | Проверка аутентификации в MCP Gateway | Анализ конфигурации шлюза, правил доступа по MCP | Medium |
| Мониторинг | Включение аудита API-сервера Kubernetes | Настройка audit policy и проверка генерации логов | Medium |
Выполняйте проверки с высокой критичность ежедневно или перед каждым развертыванием. Проверки с средней и низкой критичность можно проводить еженедельно или ежемесячно. Ведите историю аудитов для отслеживания прогресса.
План действий по результатам аудита: приоритизация исправлений
Если аудит обнаружил множество проблем, приоритизируйте исправления по матрице риска: критичность уязвимости (CVSS) и простота ее эксплуатации.
Первоочередные исправления:
- Критические уязвимости в образах (CVSS >= 9.0).
- Открытый Docker socket без аутентификации.
- Привилегированные пода с
privileged: trueилиhostPID. - Избыточные права RBAC, дающие
cluster-admin. - Отсутствие Network Policies в production-неймспейсах.
Стратегия исправления зависит от типа проблемы. Уязвимости в образах требуют патчинга или замены базового образа. Конфигурационные ошибки (например, icc=true) исправляются реконфигурацией и перезапуском демона. Проблемы RBAC решаются пересмотром ролей и привязок.
Все исправления сначала тестируйте в staging-среде. Коммуницируйте с командой разработки о найденных уязвимостях в образах, предоставляя конкретные CVE и рекомендации по обновлению.
Регулярный аудит безопасности - не разовая задача, а процесс. Интегрируйте ключевые проверки в ваш CI/CD, используйте инструменты автоматизации и следите за новыми угрозами. Для более широкого контекста аудита безопасности всей IT-инфраструктуры, включая веб-приложения и API, обратитесь к специализированным руководствам и методикам тестирования API.
Для работы с AI-моделями в безопасной и управляемой среде рассмотрите использование специализированных сервисов, таких как AiTunnel, который предоставляет единый интерфейс для более 200 моделей нейросетей с управлением бюджетами и ключами без необходимости VPN.