Практическое руководство по аудиту безопасности контейнеров и Kubernetes-кластера | AdminWiki
Logo

Практическое руководство по аудиту безопасности контейнеров и Kubernetes-кластера

24 августа 2026 7 мин. чтения
Содержание статьи

Введение: зачем нужен аудит безопасности контейнеров и Kubernetes

Аудит безопасности контейнеров и Kubernetes-кластера - это системная проверка конфигурации Docker, образов, прав доступа и сетевых политик. Цель - найти уязвимости до того, как их найдет атакующий. По данным 2026 года, основные векторы атак сместились с прямого взлома демона Docker на эксплуатацию избыточных RBAC-прав, уязвимых образов из публичных реестров и отсутствие сетевой изоляции между подами.

Эта статья дает готовый план проверки. Вы получите конкретные команды для Docker Bench, Trivy, Kube-bench и kubectl. Разберем типичные ошибки: привилегированные контейнеры, тег latest, открытые порты, отсутствие NetworkPolicies. Материал актуален для Kubernetes 1.30+ и Docker 26+ на август 2026 года.

Перед началом рекомендую ознакомиться с полным чек-листом аудита Docker и Kubernetes на 2026 год. Там собраны расширенные проверки CIS Benchmark и управление секретами.

Подготовка к аудиту: что нужно проверить

Область аудита охватывает четыре компонента: Docker-хост, реестр образов, Kubernetes-кластер и сетевую подсистему. Для каждого компонента есть свой инструмент и набор проверок.

Необходимые инструменты и доступ

Для полного аудита понадобятся пять инструментов:

  • Docker Bench Security - проверка конфигурации Docker-демона и контейнеров по CIS Benchmark.
  • Trivy - сканирование образов на известные CVE и неправильные конфигурации.
  • Kube-bench - проверка Kubernetes-кластера на соответствие CIS Kubernetes Benchmark.
  • Kube-hunter - поиск уязвимых точек входа в кластер извне.
  • kubectl - ручная проверка RBAC, NetworkPolicies, PodSecurityPolicies.

Для аудита Docker-хоста нужен root-доступ или членство в группе docker. Для Kubernetes - права cluster-admin или RBAC-роль с доступом на чтение всех ресурсов кластера. Без этих прав часть проверок будет неполной.

Если вы только начинаете систематизировать безопасность инфраструктуры, посмотрите стратегию аудита IT-инфраструктуры на 2026 год. Там разобраны этапы планирования и выбора между внутренним и внешним аудитом.

Аудит безопасности Docker-конфигурации

Docker Bench Security проверяет более 200 параметров конфигурации. Инструмент запускается контейнером и монтирует файловую систему хоста в режиме только для чтения. Результат - список проверок с пометками Pass, Warn, Info и Note.

Запуск Docker Bench Security

Команда для запуска:

docker run --rm -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 \
  --label docker_bench_security \
  docker/docker-bench-security

Вывод сгруппирован по разделам: Host Configuration, Docker Daemon Configuration, Container Images and Build Files, Container Runtime. Строки с Warn требуют внимания. Строки с Pass подтверждают корректную настройку.

Ключевые проверки Docker Bench

Пять проверок критичны для безопасности:

  1. Демон не должен слушать TCP-порт без TLS. Если Docker API открыт на 2375 порту без шифрования, любой, кто достиг этого порта, получает root на хосте. Проверка: раздел Docker Daemon Configuration, пункт про авторизацию.
  2. Контейнеры не должны запускаться с --privileged. Привилегированный контейнер имеет доступ ко всем устройствам хоста. Проверка: Container Runtime, пункт про privileged containers.
  3. Установлены лимиты памяти и CPU. Без лимитов один контейнер может исчерпать ресурсы хоста. Проверка: Container Runtime, пункты про memory и cpu limits.
  4. Используется user namespace. Переназначение UID изолирует root в контейнере от root на хосте. Проверка: Docker Daemon Configuration, пункт про userns-remap.
  5. Включен аудит файловой системы. Без аудита изменения в /etc/docker и /var/lib/docker остаются незамеченными. Проверка: Host Configuration, пункт про auditd.

Исправление каждой Warn-проверки сводится к правке /etc/docker/daemon.json и перезапуску демона. Например, для включения user namespace:

{
  "userns-remap": "default"
}

После изменения выполните systemctl restart docker и повторно запустите Docker Bench для подтверждения.

Сканирование образов контейнеров на уязвимости

Образы из публичных реестров содержат в среднем 180 известных уязвимостей. Сканирование перед развертыванием снижает риск эксплуатации через устаревшие библиотеки. Trivy сканирует слои образа, определяет установленные пакеты и сверяет их с базами CVE.

Установка и использование Trivy

Установка на Linux:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

Сканирование образа:

trivy image nginx:latest

Вывод содержит таблицу с колонками: Library, Vulnerability, Severity, Installed Version, Fixed Version. Severity бывает LOW, MEDIUM, HIGH, CRITICAL. Для продакшена порог блокировки - HIGH и CRITICAL. Обновление образа до версии с исправлением из колонки Fixed Version закрывает уязвимость.

Интеграция сканирования в CI/CD

Автоматизация сканирования на этапе сборки предотвращает попадание уязвимых образов в реестр. Пример шага для GitLab CI:

security_scan:
  stage: test
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  allow_failure: false

Параметр --exit-code 1 завершает пайплайн с ошибкой при обнаружении уязвимостей HIGH или CRITICAL. Это блокирует сборку до устранения проблемы.

Для более глубокой интеграции безопасности в процесс разработки изучите практический справочник по DevSecOps в 2026 году. Там есть 90-дневный план внедрения и модель RACI.

Аудит безопасности Kubernetes-кластера

Kubernetes-кластер требует проверки на четырех уровнях: control plane, worker nodes, RBAC и сетевая политика. Kube-bench автоматизирует проверку первых двух уровней по CIS Kubernetes Benchmark.

Запуск Kube-bench

Запуск в кластере:

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

Просмотр результатов:

kubectl logs -f job/kube-bench

Результаты сгруппированы по секциям: master, node, etcd, policies. Каждая проверка имеет номер CIS-пункта, описание и статус. Проверки с FAIL указывают на несоответствие стандарту.

Проверка RBAC

RBAC - основной механизм разграничения доступа в Kubernetes. Избыточные права позволяют скомпрометированному поду получить контроль над кластером. Проверьте права текущего пользователя:

kubectl auth can-i --list

Найдите всех субъектов с правами cluster-admin:

kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

Если cluster-admin назначен сервисным аккаунтам или группам, это повод для немедленного пересмотра. Принцип наименьших привилегий: каждый субъект получает только те права, которые нужны для его задачи. Подробный разбор настройки RBAC есть в руководстве по аудиту Kubernetes за 5 шагов.

Проверка NetworkPolicies

Без NetworkPolicies все поды в кластере могут общаться друг с другом. Это значит, что скомпрометированный веб-под может напрямую обращаться к базе данных. Проверьте наличие политик:

kubectl get networkpolicies --all-namespaces

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - port: 5432

Политика разрешает входящий трафик к подам postgres только от подов backend по порту 5432. Весь остальной трафик блокируется.

Проверка PodSecurityPolicies

PodSecurityPolicies (PSP) ограничивают, какие параметры безопасности могут запрашивать поды. В Kubernetes 1.25+ PSP заменены на Pod Security Admission (PSA). Проверьте, какой механизм используется в вашем кластере:

kubectl get psp

Если вывод пуст, проверьте PSA-режимы для неймспейсов:

kubectl get namespaces --show-labels | grep pod-security

Метка pod-security.kubernetes.io/enforce=restricted означает, что неймспейс запрещает привилегированные контейнеры. Отсутствие меток означает отсутствие ограничений. Для продакшена минимум - режим baseline, который запрещает привилегированные контейнеры и hostPath-тома.

Типичные ошибки конфигурации и как их избежать

Семь ошибок встречаются в большинстве кластеров. Каждая создает конкретный вектор атаки.

  • Привилегированные контейнеры. Контейнер с --privileged или securityContext.privileged: true имеет доступ ко всем устройствам хоста. Последствие: побег из контейнера дает root на ноде. Исправление: удалить флаг, использовать capabilities для точечного добавления прав.
  • Отсутствие лимитов ресурсов. Без resources.limits один под может занять всю память ноды. Последствие: отказ в обслуживании для остальных подов. Исправление: задать limits и requests для каждого контейнера.
  • Тег latest в продакшене. Тег latest недетерминирован и может указывать на разные версии образа. Последствие: невозможно отследить, какая версия с уязвимостью запущена. Исправление: использовать версионные теги или digest.
  • Открытые порты Docker API. Демон, слушающий на 2375 без TLS, дает полный контроль над хостом. Последствие: удаленное выполнение команд от имени root. Исправление: использовать socket, включить TLS, ограничить доступ файрволом.
  • Секреты в манифестах. Пароли и токены в YAML-файлах попадают в git-историю. Последствие: утечка учетных данных. Исправление: использовать Kubernetes Secrets, Sealed Secrets или внешние хранилища.
  • Отсутствие NetworkPolicies. Все поды общаются без ограничений. Последствие: горизонтальное перемещение атакующего внутри кластера. Исправление: создать политики для каждого неймспейса.
  • Избыточные RBAC-права. Роли с cluster-admin у сервисных аккаунтов. Последствие: скомпрометированный под получает контроль над кластером. Исправление: регулярный аудит rolebindings и удаление неиспользуемых прав.

Автоматизация аудита безопасности

Ручной аудит дает срез состояния на момент проверки. Непрерывный аудит обнаруживает аномалии в реальном времени. Два инструмента закрывают эту задачу.

Falco мониторит системные вызовы и события Kubernetes. Правила описывают подозрительное поведение: запуск shell в контейнере, запись в /etc, неожиданные сетевые соединения. Установка через Helm:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco --namespace falco --create-namespace

При обнаружении нарушения Falco отправляет алерт в настроенный канал: Slack, email, SIEM.

OPA Gatekeeper проверяет манифесты на соответствие политикам до применения в кластере. Политика, запрещающая привилегированные контейнеры:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: no-privileged-containers
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]

При попытке создать под с privileged: true Gatekeeper отклоняет запрос. Это предотвращает появление небезопасных конфигураций.

Заключение: чек-лист для регулярного аудита

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

Чек-лист для каждой проверки:

  1. Запустить Docker Bench Security, устранить все Warn-проверки.
  2. Запустить Trivy для всех образов в реестре, обновить образы с HIGH и CRITICAL уязвимостями.
  3. Запустить Kube-bench, устранить все FAIL-проверки.
  4. Проверить RBAC: kubectl auth can-i --list, найти лишние cluster-admin.
  5. Проверить NetworkPolicies: kubectl get networkpolicies --all-namespaces.
  6. Проверить Pod Security Admission: kubectl get namespaces --show-labels | grep pod-security.
  7. Проверить логи Falco за период, разобрать все алерты.
  8. Обновить политики Gatekeeper при изменении требований безопасности.

Для комплексного аудита всей IT-инфраструктуры используйте готовый план аудита за 1 день. Там есть шаблоны отчетов и чек-листы в CSV.

Поделиться:
Сохранить гайд? В закладки браузера