Модуль security-events-manager в составе в Deckhouse Kubernetes Platform (DKP) выполняет декларативный сбор, обработку, нормализацию и доставку событий безопасности, извлекаемых из логов приложений и инфраструктурных компонентов Kubernetes.

Событие безопасности — это структурированная запись о значимом с точки зрения информационной безопасности (ИБ) действии или факте. Типовые категории таких событий:

  • аутентификация и авторизация;
  • доступ к API и конфигурации;
  • изменения объектов кластера;
  • аномалии рантайма и сетевой активности.

Независимо от исходного формата лога, на выходе формируется единообразная модель события с обязательным минимумом атрибутов.

Модуль security-events-manager находится в стадии Experimental. Описанная архитектура может измениться в будущих версиях.

Архитектура решения

Архитектура предназначена для построения единого контура работы с событиями безопасности, извлекаемыми из логов приложений и инфраструктурных компонентов Kubernetes. Модуль выполняет три этапа обработки:

  1. Сбор — сбор логов из подов и файлов на узлах, первичный отбор записей, потенциально содержащих события безопасности.
  2. Обработка и обогащение — парсинг логов, извлечение признаков события, преобразование в единую модель и обогащение контекстом.
  3. Доставка — фильтрация по политике и отправка в назначенные хранилища.

На уровне доставки поддерживается отправка в несколько типов систем хранения и аналитики (например, Loki, Elasticsearch, Kafka, Splunk, Vector, File).

Пайплайн обработки

Схема пайплайна обработки

Архитектура разделяет три фазы пайплайна: сбор, обработка и обогащение, доставка.

Слой сбора (log-shipper)

Сбор выполняется через вспомогательный модуль log-shipper:

  • для контейнерных источников используются логи приложений в неймспейсе;
  • для кластерных источников используются файлы на узлах и логи системных сервисов (например, /var/log/kube-audit/audit.log, /var/log/auth.log).

Применяется двухуровневая схема:

  • модуль log-shipper выполняет предварительный отбор логовых записей с помощью простых операций сравнения (In, NotIn, Regex, NotRegex, Exists, DoesNotExist) и передаёт их в шлюз;
  • модуль security-events-manager (шлюз) выполняет парсинг полей, последующую обработку и отправку.

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

Пример исходного лога для этапа отбора:

{
  "time": "2026-05-10T14:21:03Z",
  "kind": "Event",
  "source": "kube-apiserver",
  "level": "Metadata",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401,
  "requestURI": "/api/v1/namespaces/default/secrets",
  "user": "system:serviceaccount:default:demo",
  "sourceIPs": [
    "206.123.145.70"
  ]
}

Обработка и извлечение событий

После передачи в шлюз (gateway) выполняется распознавание структуры логов. Поддерживаются стандартные стратегии обработки:

  • JSON — для структурированных логов;
  • Regex — для строковых форматов с предсказуемым шаблоном;
  • Grok — для сложных неунифицированных форматов.

Результат обработки используется для извлечения признаков события и построения унифицированного набора полей.

Пример результата этапа обработки:

{
  "parsed": {
    "timestamp": "2026-05-10T14:21:03Z",
    "source_component": "kube-apiserver",
    "http_status": 401,
    "request_uri": "/api/v1/namespaces/default/secrets",
    "actor_id": "system:serviceaccount:default:demo",
    "source_ip": "206.123.145.70"
  }
}

После обработки запись становится источником полей для классификации события (код/категория/критичность (severity)/результат (outcome)), а также для построения контекста (actor, сетевые атрибуты, метаданные источника).

Преобразование и обогащение события

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

  1. Transform — сопоставление полей исходного лога с полями целевой модели события.
  2. Enrich — добавление или уточнение полей из дополнительных источников контекста (например, статических атрибутов среды, роли субъекта, служебных признаков).

Порядок фиксирован: сначала применяется Transform, затем Enrich. При конфликте целевого поля итоговое значение определяется этапом Enrich.

Фильтрация и доставка событий

После формирования события применяется политика доставки:

  • фильтрация по источникам;
  • фильтрация по минимальному уровню критичности;
  • маршрутизация в одно или несколько назначений.

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

В качестве назначений используются системы хранения и обработки событий: кластерный Loki, внешние SIEM/лог-платформы и потоковые шины. Схема доставки поддерживает параллельную отправку в несколько целевых систем.

Модель события безопасности

Ниже приведена структура события, которое отправляется в хранилище.

Обязательные поля:

  • id, timestamp;
  • source.component;
  • event.code, event.category, event.severity, event.outcome;
  • eventMetadata.cluster.

Опциональные поля:

  • eventMetadata.sourceIPs;
  • actor.*;
  • object.*.
{
  "id": "2f0de5c2-2e58-4d3f-b4fe-5ec6f1935b9f",
  "timestamp": "2026-05-10T14:21:03Z",
  "source": {
    "component": "kube-apiserver"
  },
  "event": {
    "code": "UNAUTHORIZED_ACCESS",
    "category": "Rbac",
    "severity": "High",
    "outcome": "Failure"
  },
  "eventMetadata": {
    "cluster": "prod-cluster",
    "sourceIPs": [
      "206.123.145.70"
    ]
  },
  "actor": {
    "id": "system:serviceaccount:default:demo",
    "type": "ServiceAccount"
  },
  "object": {
    "id": "/api/v1/namespaces/default/secrets",
    "type": "KubernetesResource"
  }
}

Минимально достаточный цикл работы

В практическом сценарии архитектура работает по следующей цепочке:

  1. Источники логов подключаются к контуру сбора.
  2. Выполняется первичный отбор потенциально релевантных записей.
  3. Записи обрабатываются и преобразуются в унифицированные события.
  4. События обогащаются контекстными атрибутами.
  5. Применяются правила фильтрации и маршрутизации.
  6. События отправляются в целевые хранилища и аналитические системы.

Итогом является единый и управляемый поток событий безопасности, пригодный для мониторинга, анализа и долгосрочного аудита.

Поддерживаемые события безопасности

Модуль security-events-manager поставляется со встроенным набором правил обнаружения событий безопасности, охватывающим аутентификацию, конфигурацию, RBAC, среду выполнения и другие категории. Актуальный перечень реализованных событий безопасности, их коды, критичность и описание приведены в документации модуля.

Дополнительные ресурсы