Система безопасного мониторинга Kubernetes строится на трёх компонентах: Cilium Hubble контролирует сетевые потоки и выявляет аномалии, Falco обеспечивает runtime-безопасность контейнеров, а kube-bench проверяет кластер на соответствие стандартам CIS. Эта статья - практическое руководство по их внедрению и интеграции в единую архитектуру с Prometheus, Grafana и Alertmanager.
Контейнерные среды растут, и вместе с ними растёт поверхность атаки. Злоумышленники эксплуатируют неправильные конфигурации API-сервера, уязвимые образы и слабую сетевую изоляцию. Без специализированного мониторинга безопасности вы рискуете пропустить инцидент на ранней стадии. Дальше - пошаговые инструкции, которые помогут вам развернуть эшелонированную защиту и наладить алертинг на критические события.
Зачем нужен безопасный мониторинг в Kubernetes
Стандартный мониторинг CPU, памяти и дисков не показывает, что конкретный под неожиданно открыл shell-сессию или отправил данные на подозрительный внешний IP. Безопасный мониторинг закрывает этот пробел. Он отвечает на три ключевых вопроса:
- Кто с кем общается в сети кластера и есть ли аномалии в трафике?
- Что происходит внутри контейнеров прямо сейчас - не запускаются ли вредоносные процессы?
- Соответствует ли конфигурация кластера лучшим практикам безопасности?
Ответы дают три инструмента: Cilium Hubble для сетевого контроля, Falco для runtime-детектирования и kube-bench для аудита конфигураций. Вместе они формируют три столпа безопасного мониторинга. Если вы уже используете Prometheus и Grafana для метрик производительности, вы сможете добавить к ним метрики безопасности и получить единую панель для контроля инфраструктуры.
Обзор инструментов для мониторинга безопасности
Выбор инструментов не случаен. Hubble использует eBPF для глубокой видимости сетевых потоков без накладных расходов на зеркалирование трафика. Falco перехватывает системные вызовы ядра и сопоставляет их с правилами угроз. kube-bench - эталонный инструмент от Aqua Security для проверки соответствия CIS Kubernetes Benchmark. Ниже - детальный разбор каждого.
Cilium Hubble: контроль сетевых потоков и обнаружение аномалий
Hubble - это слой наблюдаемости поверх Cilium CNI. Он строит карту сервисов в реальном времени: вы видите, какой под общается с каким, по какому протоколу, на каком порту и с какой интенсивностью. Эта видимость критична для обнаружения аномалий.
Hubble отвечает на практические вопросы безопасности:
- Почему под из namespace «frontend» пытается подключиться к базе данных напрямую, минуя API-сервис?
- Какой процесс инициировал исходящее соединение на нестандартный порт за пределы кластера?
- Есть ли в кластере скрытое сканирование портов между подами?
В основе Hubble - технология eBPF, которая встраивает программы наблюдения в ядро без модификации приложений. Вы получаете метаданные Kubernetes (namespace, pod, labels) для каждого сетевого потока. Это позволяет строить сетевые политики и алертить на их нарушения. Например, вы можете определить политику «под с меткой app=payment-processor может принимать входящие соединения только от подов с меткой app=api-gateway на порт 8443» и получать уведомление при каждом нарушении.
Falco: runtime-безопасность контейнеров
Falco - это инструмент от команды Sysdig, который работает на уровне системных вызовов ядра Linux. Он отслеживает поведение процессов в контейнерах и сравнивает его с набором правил. Если поведение отклоняется от нормы, Falco генерирует событие безопасности.
Типичные сценарии, которые детектирует Falco:
- Запуск оболочки (shell) внутри работающего контейнера - частый признак компрометации.
- Изменение бинарных файлов или библиотек в /bin, /usr/bin.
- Чтение или запись в чувствительные файлы, такие как /etc/shadow.
- Монтирование томов с хостовой файловой системой в контейнер.
- Создание привилегированных подов или контейнеров с флагом --privileged.
Falco интегрируется с Kubernetes API и обогащает события метаданными: namespace, pod name, container ID, image. Это превращает сырой системный вызов в осмысленный алерт: «В поде payment-processor-7d4f5b9c8-xk2lm контейнера payment-app запущен процесс /bin/bash пользователем root». С таким контекстом время реакции на инцидент сокращается с часов до минут.
kube-bench: аудит соответствия стандартам CIS
CIS Kubernetes Benchmark - это набор из более чем 100 проверок безопасности, разработанный Center for Internet Security. Он охватывает master-узлы, worker-узлы, политики безопасности, настройки etcd, API-сервера, controller manager и scheduler. kube-bench автоматизирует эти проверки.
Инструмент запускается как Job или DaemonSet внутри кластера и за несколько минут выдаёт отчёт. Каждая проверка получает статус: PASS, FAIL или WARN. Типичные уязвимости, которые находит kube-bench:
- Анонимный доступ к API-серверу (флаг --anonymous-auth=true).
- Отсутствие авторизации AlwaysAllow в режиме RBAC.
- Небезопасные настройки etcd - отсутствие аутентификации между пирами.
- Использование стандартных портов без TLS.
- Отсутствие ограничений на использование hostPID и hostIPC в подах.
Результаты kube-bench - это не просто список проблем, а приоритизированный план действий. Критические проверки требуют немедленного исправления, предупреждения указывают на потенциальные риски, информационные сообщения дают рекомендации по усилению защиты.
Установка и настройка Cilium Hubble
Предварительное требование - Cilium CNI, установленный в режиме Kubernetes. Hubble включается поверх него. Если у вас ещё нет Cilium, начните с микросегментации Kubernetes с Cilium - там пошаговый гайд по установке и настройке сетевых политик.
Установка Hubble CLI на локальную машину:
export HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-amd64.tar.gz
tar xzvf hubble-linux-amd64.tar.gz
sudo mv hubble /usr/local/bin/
Включение Hubble в кластере через Helm:
helm upgrade cilium cilium/cilium --namespace kube-system \
--set hubble.relay.enabled=true \
--set hubble.ui.enabled=true \
--set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,http}"
Hubble Relay агрегирует потоки со всех узлов и предоставляет единую точку доступа для CLI и UI. Hubble UI - веб-интерфейс для визуализации карты сервисов. Метрики включают DNS-запросы, дропнутый трафик, TCP-соединения, распределение портов, ICMP и HTTP-запросы.
Проверка работоспособности:
hubble status
hubble observe
Команда hubble observe выводит поток событий в реальном времени. Вы увидите каждое сетевое соединение с метаданными Kubernetes.
Визуализация сетевых потоков и поиск аномалий
Hubble UI доступен через port-forward:
kubectl port-forward -n kube-system svc/hubble-ui 12000:80
В браузере открывается карта сервисов. Каждый узел - под или сервис. Рёбра - сетевые потоки. Цвет рёбер показывает статус соединения: зелёный - успешное, красный - дропнутое политикой. Фильтры позволяют сузить область анализа до конкретного namespace, pod или label.
Практические примеры поиска аномалий через CLI:
# Все исходящие соединения на внешние IP из namespace production
hubble observe --from-namespace production --to-fqdn ".*"
# Дропнутый трафик за последние 5 минут
hubble observe --verdict DROPPED --last 5m
# Соединения на нестандартные порты
hubble observe --to-port 4444 --to-port 5555
Сканирование портов проявляется как серия коротких TCP-соединений с одного пода на множество портов другого пода. В выводе Hubble это выглядит как повторяющиеся записи с флагом TCP и разными портами назначения за короткий промежуток времени.
Настройка алертов на основе сетевых политик
Cilium Network Policies позволяют определить разрешённый трафик на уровне L3/L4 и L7. Hubble логирует каждое нарушение политики. Чтобы превратить логи в алерты, настройте экспорт метрик в Prometheus:
helm upgrade cilium cilium/cilium --namespace kube-system \
--set hubble.metrics.enabled="{drop}" \
--set prometheus.enabled=true \
--set operator.prometheus.enabled=true
Метрика hubble_drop_total содержит счётчик дропнутого трафика с лейблами source_pod, destination_pod, destination_port и policy_name. Правило алертинга Prometheus:
- alert: NetworkPolicyViolation
expr: rate(hubble_drop_total[5m]) > 0.1
for: 1m
labels:
severity: warning
annotations:
summary: "Нарушение сетевой политики: {{ $labels.source_pod }} -> {{ $labels.destination_pod }}:{{ $labels.destination_port }}"
Это правило срабатывает, когда трафик дропается сетевой политикой с частотой более 0.1 события в секунду в течение минуты. Алерт приходит в Alertmanager, который маршрутизирует его в Slack, Telegram или на вебхук.
Внедрение Falco для обнаружения угроз в реальном времени
Установка Falco через Helm:
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
--namespace falco --create-namespace \
--set falcosidekick.enabled=true \
--set falcosidekick.webui.enabled=true \
--set driver.kind=ebpf
Драйвер eBPF предпочтителен для современных ядер (5.8+). Он работает без загрузки модуля ядра и снижает накладные расходы. Falcosidekick - это сайдкар, который принимает события от Falco и маршрутизирует их в десятки каналов: Slack, Teams, Datadog, Elasticsearch, Loki, Prometheus Alertmanager и другие.
После установки проверьте, что Falco детектирует события:
kubectl logs -n falco -l app.kubernetes.io/name=falco -f
Для теста запустите shell в любом поде:
kubectl exec -it any-pod -- /bin/bash
В логах Falco появится событие с правилом "Terminal shell in container". Это подтверждает, что runtime-мониторинг работает.
Ключевые правила Falco для Kubernetes
Falco поставляется с набором правил по умолчанию, но для production-среды их нужно адаптировать. Вот критически важные правила, которые стоит включить или модифицировать:
# Запуск shell в контейнере
- rule: Terminal shell in container
desc: Detect bash, sh, zsh execution in a container
condition: spawned_process and container and proc.name in (bash, sh, zsh)
output: "Shell opened in container (user=%user.name container=%container.name pod=%k8s.pod.name namespace=%k8s.ns.name)"
priority: WARNING
# Монтирование чувствительных томов
- rule: Mount sensitive host directory
desc: Detect mount of /etc, /proc, /sys from host
condition: evt.type=mount and container and (proc.args contains "/etc" or proc.args contains "/proc")
output: "Sensitive host directory mounted (container=%container.name pod=%k8s.pod.name)"
priority: CRITICAL
# Запись в /etc внутри контейнера
- rule: Write below etc
desc: Detect writes to /etc inside container
condition: evt.type=openat and evt.is_open_write=true and container and fd.name startswith /etc
output: "File in /etc modified (file=%fd.name container=%container.name pod=%k8s.pod.name)"
priority: WARNING
# Создание привилегированного пода
- rule: Create privileged pod
desc: Detect creation of a pod with privileged security context
condition: kevt and pod and kcreate and ka.req.pod.containers.privileged intersects (true)
output: "Privileged pod created (pod=%k8s.pod.name namespace=%k8s.ns.name)"
priority: CRITICAL
Правила хранятся в ConfigMap и монтируются в под Falco. Для применения изменений отредактируйте ConfigMap и перезапустите поды:
kubectl edit configmap falco-rules -n falco
kubectl rollout restart daemonset/falco -n falco
Тестируйте правила в staging-среде перед развёртыванием в production. Используйте утилиту event-generator из проекта Falco для симуляции угроз.
Экспорт событий и настройка уведомлений
Falcosidekick настраивается через values.yaml при установке Helm. Пример конфигурации для отправки алертов в Slack и Prometheus Alertmanager:
falcosidekick:
enabled: true
config:
slack:
webhookurl: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
minimumpriority: "warning"
alertmanager:
hostport: "http://alertmanager.monitoring.svc:9093"
minimumpriority: "critical"
Для дашборда событий в Grafana направьте события в Loki или Elasticsearch. Falcosidekick поддерживает оба варианта. События попадают в хранилище с метаданными Kubernetes, и вы можете построить дашборд с графиком событий по severity, namespace и типу правила.
Аудит безопасности кластера с kube-bench
kube-bench запускается как Kubernetes Job. Он выполняет проверки для роли, которую вы укажете: master, node, etcd, policies, managedservices. Для полного аудита запустите Job на master-узлах с соответствующими монтированиями конфигурационных файлов.
Пример манифеста для запуска на master-узле:
apiVersion: batch/v1
kind: Job
metadata:
name: kube-bench-master
spec:
template:
spec:
hostPID: true
nodeSelector:
node-role.kubernetes.io/master: ""
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
containers:
- name: kube-bench
image: aquasec/kube-bench:latest
command: ["kube-bench", "--benchmark", "cis-1.8"]
volumeMounts:
- name: var-lib-etcd
mountPath: /var/lib/etcd
readOnly: true
- name: etc-kubernetes
mountPath: /etc/kubernetes
readOnly: true
restartPolicy: Never
volumes:
- name: var-lib-etcd
hostPath:
path: /var/lib/etcd
- name: etc-kubernetes
hostPath:
path: /etc/kubernetes
Флаг --benchmark cis-1.8 указывает версию CIS Benchmark. Актуальную версию уточняйте в документации kube-bench - на июль 2026 года это CIS 1.8 для Kubernetes 1.29+.
После завершения Job получите логи:
kubectl logs job/kube-bench-master
Отчёт содержит секции с результатами проверок. Каждая проверка имеет номер, описание и статус. Пример вывода:
[FAIL] 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive
[PASS] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root
[WARN] 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive
Приоритизация исправлений: сначала критические FAIL, затем WARN, затем информационные сообщения. Критические проверки часто связаны с анонимным доступом, отсутствием авторизации и небезопасными настройками TLS.
Автоматизация проверок и интеграция в CI/CD
Разовый аудит полезен, но регулярные проверки критичны. Настройте CronJob для еженедельного запуска kube-bench:
apiVersion: batch/v1
kind: CronJob
metadata:
name: kube-bench-weekly
spec:
schedule: "0 3 * * 1" # Каждый понедельник в 3:00
jobTemplate:
spec:
template:
spec:
hostPID: true
nodeSelector:
node-role.kubernetes.io/master: ""
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
containers:
- name: kube-bench
image: aquasec/kube-bench:latest
command: ["kube-bench", "--benchmark", "cis-1.8", "--json"]
restartPolicy: Never
Флаг --json выводит результаты в машиночитаемом формате. Эти данные можно экспортировать в Prometheus через Pushgateway или направить в Elasticsearch для долгосрочного хранения и анализа трендов. Метрика compliance_score показывает процент пройденных проверок с течением времени - падение этого показателя сигнализирует о регрессии в безопасности.
Для интеграции в CI/CD запускайте kube-bench при добавлении новых узлов в кластер. Если новый узел не соответствует CIS, пайплайн должен блокировать его ввод в эксплуатацию до устранения проблем.
Сбор метрик безопасности и централизованный алертинг
Все три инструмента - Hubble, Falco, kube-bench - экспортируют метрики в Prometheus. Архитектура централизованного сбора:
- Hubble экспортирует метрики сетевых потоков и дропнутого трафика через встроенный Prometheus endpoint.
- Falco экспортирует события через Falcosidekick в Alertmanager или через отдельный экспортер falco-exporter.
- kube-bench результаты пушатся в Pushgateway или собираются через скрипт, который парсит JSON-вывод и отдаёт метрики.
Prometheus собирает метрики, Alertmanager обрабатывает алерты и маршрутизирует их в каналы уведомлений, Grafana визуализирует данные. Для развёртывания этого стека используйте пошаговую настройку мониторинга Kubernetes с Prometheus и Grafana - там готовые манифесты и конфигурации для production.
Создайте дашборд «Безопасность Kubernetes» в Grafana со следующими панелями:
- График дропнутого трафика по namespace (метрика hubble_drop_total).
- Счётчик событий Falco по severity (critical, warning, notice).
- Тренд compliance score kube-bench за последние 30 дней.
- Топ-10 подов с наибольшим количеством нарушений сетевых политик.
- Временная шкала событий Falco с фильтром по типу правила.
Этот дашборд даёт срез состояния безопасности за 5 секунд. Для глубокого анализа используйте руководство по наблюдаемости для высоконагруженных систем с готовыми шаблонами алертов и дашбордов.
Примеры критических алертов и реакция на инциденты
Алерты делятся на три уровня severity: critical (немедленная реакция), warning (требует внимания в течение часа), info (для аудита и трендов).
Critical: Запущен shell в production-контейнере. Алерт от Falco. Runbook: изолировать под (cordon node, delete pod), проверить логи контейнера на предмет вредоносной активности, просканировать образ на уязвимости, проверить RBAC на предмет эскалации привилегий, инициировать расследование инцидента.
Critical: Обнаружено сканирование портов. Алерт от Hubble (резкий рост дропнутого трафика на множество портов с одного source IP). Runbook: изолировать source pod, проверить целостность образа, проанализировать исходящие соединения за последние 24 часа, проверить соседние поды на признаки компрометации.
Warning: Создан привилегированный под. Алерт от Falco. Runbook: проверить, кто создал под (kubectl get events, audit logs), сопоставить с RBAC и политиками безопасности, удалить под если неавторизован, ужесточить PodSecurityPolicy или OPA-правила.
Warning: Снижение compliance score ниже 80%. Алерт от kube-bench. Runbook: запустить внеочередной аудит, определить новые FAIL-проверки, назначить ответственного за исправление, отслеживать тренд до возврата к целевому уровню.
Анализ логов для расследования инцидентов
Метрики и алерты указывают на инцидент. Логи дают контекст для расследования. Три источника логов безопасности в Kubernetes:
- Kubernetes Audit Logs - запись каждого обращения к API-серверу: кто, когда, к какому ресурсу, с каким результатом.
- События Falco - детальная запись каждого подозрительного системного вызова с метаданными пода.
- Логи Hubble - запись каждого сетевого потока с verdict (FORWARDED, DROPPED, ERROR).
Для сбора и анализа используйте Loki или Elasticsearch. Loki легче в установке и интегрируется с Grafana «из коробки». Elasticsearch даёт более мощный полнотекстовый поиск для сложных расследований.
Корреляция событий - ключ к восстановлению цепочки атаки. Пример: алерт Falco о запуске shell в поде. Вы открываете Kubernetes Audit Logs и видите, что за минуту до этого была выполнена команда kubectl exec с учётной записью, которая не должна иметь такого доступа. Затем в логах Hubble видите, что после запуска shell под установил исходящее соединение на внешний IP. Цепочка: компрометация учётной записи → доступ к поду → запуск shell → эксфильтрация данных. Каждый шаг подтверждён логами из независимых источников.
Настройте хранение логов безопасности не менее 90 дней для соответствия требованиям регуляторов и возможности ретроспективного анализа. Используйте сжатие и tiered storage для оптимизации затрат.
Заключение: построение комплексной системы безопасного мониторинга
Комплексная система безопасного мониторинга Kubernetes опирается на три компонента: Cilium Hubble для сетевого контроля, Falco для runtime-безопасности и kube-bench для аудита конфигураций. Они интегрируются с Prometheus, Alertmanager и Grafana в единую архитектуру сбора метрик, алертинга и визуализации.
Регулярно обновляйте правила Falco и версию CIS Benchmark для kube-bench. Угрозы эволюционируют, и инструменты должны соответствовать актуальному ландшафту. Проводите аудит безопасности не реже раза в месяц и после каждого значительного изменения в кластере. Для углублённого аудита инфраструктуры используйте комплексный план аудита безопасности с готовыми чек-листами и шаблонами отчётов.
Начните с малого: установите Falco и настройте алерты на запуск shell в production-подах. Затем добавьте Hubble для видимости сетевых потоков. Завершите внедрением kube-bench для регулярного аудита. Каждый шаг даёт измеримый прирост безопасности без перегрузки команды ложными срабатываниями.