Мониторинг безопасности Kubernetes в SOC/SIEM: Audit, D4C, сеть и ноды

Что мониторим

Фраза «собираем логи Kubernetes» скрывает четыре разных журнала.

API

Kubernetes audit пишет обращения к API-серверу: кто отправил запрос, что хотел сделать, к какому объекту обратился и разрешил ли сервер операцию. Так видны изменение прав, создание пода, kubectl exec, выдача токена сервисному аккаунту, admission webhook и смена NetworkPolicy, если ресурс есть в audit policy. Насколько подробно писать события, задает policy: Metadata, Request или RequestResponse.

kube-apiserver → audit policy → JSONL → kubernetes.audit_logs → audit rules

Контейнеры

D4C через eBPF смотрит процессы и файлы внутри контейнеров. Если в уже запущенном контейнере стартует процесс, обращения к API может не быть.

контейнеры → D4C/eBPF → cloud_defend.process/file/alerts → runtime rules

Сеть

Логи CNI показывают, кто к кому ходил, какое правило дропнуло пакет и на какие внешние адреса ушёл трафик. Эти данные хорошо обогащать Threat Intelligence: известный грязный домен или IP видно раньше, чем из этого вырастет в инцидент.

CNI → Hubble / Calico flow logs → Elastic Agent → network rules

Хост

EDR на ноде ловит то, что влияет на кластер, но не видно в audit, D4C и сети.

нода → Elastic Defend / host EDR → logs-endpoint.events.* → host rules

Вместе они складываются в одну картину. Audit покажет, что кому выдали права. D4C — какой процесс стартовал в контейнере. Сеть — куда ушёл трафик и нет ли этого адреса в Threat Intelligence. EDR на ноде — если API обошли и к etcd обратились с хоста, хотя сам etcd крутится в контейнере. По одному журналу этого не собрать.

Что потребуется перед настройкой

Подход к мониторингу не зависит от того, как развернут кластер. Ниже настройка audit показана на примере self-managed кластера с kubeadm. В нём нужен доступ к каждой control-plane node и к static Pod manifest, который обычно находится в /etc/kubernetes/manifests/kube-apiserver.yaml. В других дистрибутивах путь и способ подключения policy могут отличаться, а в managed-кластерах аудит включается средствами облачного провайдера.

Конфигурацию kubeadm лучше хранить в управляемом процессе или в повторяемых patches: при upgrade ручная правка manifest может быть перегенерирована. Механизм описан в документации по настройке компонентов через kubeadm API.

Перед настройкой подготовьте:

• сведения о версиях Kubernetes и Elastic;
• административный доступ к кластеру и его control plane;
• работающий Elastic Stack или Elastic Cloud с доступом к Fleet;
• место для audit-файлов на control-plane nodes, если кластер self-managed;
• тестовый namespace, в котором можно безопасно проверить появление событий.

Перед установкой D4C проверьте его совместимость с нодами кластера. Elastic обозначает D4C как Beta и указывает технический минимум: Elastic Stack 9.3+, Kubernetes 1.24+, Linux x86_64, containerd или CRI-O и ядро 5.10.16+. В ядре должна быть включена поддержка BPF-LSM, через которую D4C получает события о процессах и файлах.

Если у вас установлены Kubernetes 1.24 или более ранняя версия, ядро 5.10.16 или ниже либо containerd 1.6, советуем обновить их до поддерживаемых версий с актуальными исправлениями безопасности.

D4C-агент получает расширенный доступ к хосту: ему нужны BPF-related capabilities и host mounts. Поэтому service account, RBAC, capabilities, hostPath, область DaemonSet и возможность изменения Agent policy требуют такого же ревью, как другие привилегированные security-компоненты.

При этом расширенные полномочия агента не дают полного контроля над хостом. D4C собирает события процессов и файлов контейнеров, но не заменяет EDR на ноде. Обращение к etcd в обход API и kubectl с хоста — отдельный слой, о нём ниже.

Audit включаем на каждой control-plane node

В Kubernetes audit-событий не будет, пока kube-apiserver не получит policy. Согласно документации Kubernetes Auditing, policy определяет, какие запросы записывать и с какой детализацией, а backend отправляет их в файл или webhook.

Перед изменением сохраните исходный manifest вне /etc/kubernetes/manifests: kubelet следит за этим каталогом, поэтому резервная копия внутри него может быть принята за ещё один static Pod. Затем последовательно на каждой control-plane node:

1. Разместите policy, например в /etc/kubernetes/audit-policy.yaml.
2. Создайте каталог для JSONL и ограничьте к нему доступ.
3. Добавьте в kube-apiserver флаги --audit-policy-file, --audit-log-path и --audit-log-format=json.
4. Настройте ротацию для локального аварийного буфера; на роль долгосрочного хранилища она не рассчитана.

- --audit-policy-file=/etc/kubernetes/audit-policy.yaml
- --audit-log-path=/var/log/kubernetes/kube-apiserver-audit.log
- --audit-log-format=json

Пути внутри контейнера должны совпасть с volumeMounts, а host paths — существовать на каждой control-plane node:

volumeMounts:
 - name: audit-policy
   mountPath: /etc/kubernetes/audit-policy.yaml
   readOnly: true
 - name: audit-log
   mountPath: /var/log/kubernetes/
volumes:
 - name: audit-policy
   hostPath:
     path: /etc/kubernetes/audit-policy.yaml
     type: File
 - name: audit-log
   hostPath:
     path: /var/log/kubernetes/
     type: DirectoryOrCreate

Добавляйте лимиты maxage, maxbackup и maxsize после расчёта. Скопированные из примера числа могут удалить backlog раньше, чем агент успеет восстановить доставку.

На HA control plane меняйте по одной ноде. После каждого изменения проверяйте readiness API server, доступ через общий endpoint, отсутствие ошибок загрузки policy и появление корректных JSON Lines. Каждый экземпляр kube-apiserver пишет только принятые им запросы, поэтому собирать поток нужно со всех control-plane nodes.

Baseline policy: сохраняем полезное, а не всё подряд

Audit policy применяется сверху вниз: побеждает первое совпавшее правило. Если раннее правило уже обработало pods/exec на Metadata, более подробное правило ниже не сработает. Поля доступных селекторов и событий зафиксированы в API reference для audit.k8s.io/v1.

Уровни различаются составом данных и ценой:

• Metadata сохраняет субъект, время, verb, URI, object reference, статус и annotations без тел;
• Request добавляет тело запроса;
• RequestResponse добавляет ещё и тело ответа.

Писать всё на RequestResponse опасно: audit stream может превратиться во вторую базу секретов, а нагрузка на API server и хранение вырастут. omitManagedFields: true уменьшает объём, но не скрывает Secret, токены, env.value, аргументы или чувствительные annotations.

Ниже приведены отдельные фрагменты возможной policy. Они показывают логику настройки, но перед использованием их нужно адаптировать к своему кластеру.

Например, в стартовой policy для Secret и ConfigMap можно сохранять только метаданные:

- level: Metadata
 resources:
   - group: ""
     resources: [secrets, configmaps]

Другой пример — отдельное логирование subresources. Правило для pods не покрывает pods/exec, pods/attach или pods/portforward, поэтому их можно перечислить отдельно:

- level: Request
 resources:
   - group: ""
     resources:
       - pods/exec
       - pods/attach
       - pods/portforward
       - pods/ephemeralcontainers

Если правилу нужно содержимое запроса при изменении RBAC или workload, можно использовать уровень Request. Он добавит requestObject, но не будет копировать ответ:

- level: Request
 verbs: [create, update, patch, delete, deletecollection]
 resources:
   - group: rbac.authorization.k8s.io
     resources: [roles, rolebindings, clusterroles, clusterrolebindings]
   - group: apps
     resources: [deployments, daemonsets, statefulsets]

В этом примере policy завершается правилом catch-all. Оно сохраняет основные сведения о запросах, которые не совпали с предыдущими правилами:

- level: Metadata

Для полей requestObject.spec.* достаточно уровня Request или RequestResponse. Конкретное stock rule при этом может фильтровать точную строку уровня. Если автор правила буквально зафиксировал level == "Request", более подробное событие с level: RequestResponse не совпадёт с условием. После выбора policy сверьте контракты включаемых правил.

Есть ещё два ограничения. Для PATCH request body может содержать массив операций без полной итоговой спецификации. Уровень также нельзя выбирать по будущему responseStatus: коды 401/403 фильтруются уже в Elastic.

Файл — ещё не источник мониторинга

В self-managed кластере audit-события можно записывать в файл и забирать оттуда с помощью Elastic Agent. Такой маршрут выглядит так:

kube-apiserver file backend
→ Elastic Agent + Kubernetes Audit Logs integration
→ logs-kubernetes.audit_logs-*

По умолчанию Kubernetes audit-logs integration читает файл /var/log/kubernetes/kube-apiserver-audit.log. Тот же путь указан в настройках kube-apiserver.

Audit-события нужно отправлять с control-plane node в Elastic, а локальный файл использовать как временное хранилище. Если связь с Elastic пропадёт, неотправленные события останутся в очереди агента и в локальном файле. Для этого на диске нужно предусмотреть запас места, а ротацию настроить так, чтобы старые файлы не удалялись раньше отправки.

Централизованное хранение также сохранит историю, если control-plane node будет скомпрометирована, а локальные логи удалят или изменят. Для длительного хранения и расследований можно дополнительно отправлять копию событий в защищённый бэкап.

Для end-to-end проверки выполните обычное административное действие в выделенном namespace с уникальным безопасным маркером. В logs-kubernetes.audit_logs-* найдите именно это событие и подтвердите:

• data_stream.dataset: kubernetes.audit_logs;
• auditID, actor, verb, resource и subresource;
• stage, level, responseStatus.code и timestamps;
• authorization annotations;
• наличие конкретных requestObject-полей, которые читают выбранные правила;
• приемлемую задержку между временем события и event.ingested.

После этого на коротком контролируемом окне можно проверить восстановление очереди после временной остановки output. Ожидаемые дубликаты при повторной доставке нужно учитывать отдельно от потерь.

Если кластер в облаке, файл в kube-apiserver не монтируют. В EKS включают тип audit и забирают поток из CloudWatch Logs — AWS предупреждает, что доставка best-effort. В AKS нужен Diagnostic setting: полный kube-audit или более короткий kube-audit-admin без get/list, дальше Event Hub. В GKE записи (Admin Activity) включены всегда, чтения (Data Access) — отдельно; в Elastic идут через Log Router и Pub/Sub. Проверка та же: событие в kubernetes.audit_logs. Входы описаны в Kubernetes integration. D4C, сеть и хост из этого облачного audit не появятся — их по-прежнему забирают с нод.

D4C дополняет Audit runtime-событиямилов

Когда audit-события уже приходят в Elastic, можно подключать D4C. Он разворачивается через Elastic Agent как DaemonSet на целевых Kubernetes nodes. Интеграция использует eBPF LSM и tracepoint probes для получения системных событий. Политика определяет, какие process/file операции логировать, для каких создавать alerts и какие при необходимости блокировать.

Базовая D4C policy включает сбор process telemetry и drift detection. Elastic также предоставляет prebuilt detection rules, рассчитанные на эти события.

После установки нужно проверить:

kubectl get pods -A -o wide | grep elastic-agent

и убедиться, что DaemonSet работает на всех нужных нодах.

Затем в Fleet:

• Agent должен быть Healthy;
• policy должна применяться;
• D4C integration должна быть активна.

Но даже Healthy Agent ещё не доказывает наличие нужной telemetry.

В Elastic нужно отдельно проверить появление runtime-событий в соответствующих cloud_defend.* data streams.

Сеть требует собственных правил

Kubernetes Audit может показать NetworkPolicy changed но не означает  Pod A → Pod B :443 или Pod → 8.8.8.8:443 Для этого нужна network flow telemetry.

Cilium

В Cilium такую задачу можно решать через Hubble и его exporters.

Calico

В Calico используется Flow Logs.

Полученный поток можно отправлять в Elastic Agent и дальше анализировать как сетевую telemetry.
Типовые сценарии:

• неожиданный исходящий трафик;
• соединение с внешним IP;
• связь между неожиданными namespace;
• denied traffic;
• обращение к чувствительным сервисам;
• совпадение адреса с Threat Intelligence.

При этом нельзя считать Hubble универсальным Kubernetes-компонентом. Это механизм observability Cilium. Аналогично Calico Flow Logs относятся к Calico.

На ноде нужен свой EDR

Control-plane node — это одновременно Kubernetes-компонент и обычный Linux-хост.
На ней могут происходить события, которые не имеют прямого отражения в Kubernetes Audit:

SSH
sudo
systemd
kubelet
containerd
kubectl
файловая система
host processes
Host EDR позволяет построить цепочку:

SSH login → shell → kubectl → Kubernetes API → audit event

Вместо анализа каждого источника отдельно можно коррелировать их между собой.

Например:

host EDR:
   user → ssh → kubectl
+
Kubernetes Audit:
   user → create ClusterRoleBinding

Это значительно сильнее, чем любое из событий по отдельности.

Сток — точка старта, дальше нужны свои правила

Elastic предоставляет prebuilt rules для Kubernetes Audit и D4C. Для D4C существует отдельный набор правил, ориентированный на runtime-события контейнеров.

Например, уже существуют сценарии, связанные с:

• service account token;
• подозрительным выполнением процессов;
• сетевыми инструментами;
• shell/interpreter execution;
• созданием и изменением файлов;
• privilege escalation;
• tunneling;
• Kubernetes API activity.

Почему одного Pod event недостаточно

Особенно хорошо это видно на hostPath.

Прямой вариант:

spec:
 volumes:
   - name: host
     hostPath:
       path: /etc

виден непосредственно в событии создания Pod.

Но можно построить цепочку:

Pod → PVC → PV → hostPath

В этом случае в событии Pod останется, например:

persistentVolumeClaim:
 claimName: sensitive-pvc

а сам hostPath будет находиться в объекте PV.

Поэтому detection, смотрящий только:

audit event → Pod → volumes.hostPath

может ничего не увидеть.

Нужна корреляция объектов:

Pod → PVC → PV → hostPath

Это хороший пример общей проблемы Kubernetes detection engineering: опасное состояние может быть распределено между несколькими API-объектами.

Сеть требует собственных правил

Для Hubble и Calico Flow Logs нет смысла ожидать, что Kubernetes Audit Logs integration автоматически превратит flow telemetry в готовый набор Kubernetes network detections.

После доставки потока в Elastic собственные правила могут искать:

• Pod → known malicious IP
• Pod → unexpected Internet destination
• namespace A → namespace B
• denied connection

и затем связывать это с D4C process telemetry или Kubernetes audit

Например:

container starts curl
       ↓
curl connects to malicious IP
       ↓
Threat Intelligence match
       ↓
Kubernetes Audit shows service account

Так появляется уже не отдельное событие, а полноценная цепочка атаки.

На выходе — четыре источника и понятные границы

В результате получается не один «Kubernetes log», а несколько независимых слоёв:

Каждый источник отвечает на свой вопрос:

1. Audit: Кто и что сделал через Kubernetes API?
2. D4C: Что реально выполнялось внутри контейнера?
3. Network: Кто с кем взаимодействовал?
4. Host EDR: Что происходило непосредственно на ноде?

Полноценное обнаружение получается именно на пересечении этих источников.

Например:

Host EDR:
SSH → kubectl
       ↓
Kubernetes Audit:
ClusterRoleBinding created
       ↓
D4C:
service account token accessed
       ↓
Network:
connection to external IP

Каждое событие само по себе может быть недостаточным. Вместе они позволяют восстановить цепочку атаки.
 

Итог

Для self-managed Kubernetes минимальный security monitoring stack в Elastic можно представить так:

Kubernetes Audit
       +
D4C
       +
Network telemetry
       +
Host EDR
       ↓
    Elastic
       ↓
Detection
       ↓
Correlation
       ↓
  Investigation

Audit закрывает Kubernetes API, D4C — runtime контейнеров, network telemetry — сетевые связи, а EDR — саму ноду.

При этом ни один из источников не является заменой остальным.

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

После этого можно наращивать покрытие под модель угроз конкретного кластера и постепенно переходить от отдельных событий к корреляции между API, runtime, network и host telemetry.