Стадия жизненного цикла модуля: Экспериментальная версия

У модуля есть требования для установки

v1.2.0

Дата релиза: 2026-09-28

Выпуск снижает нагрузку сбора логов на узлы, отбрасывает события безопасности, не прошедшие проверку по реестру событий, и ограничивает схемы и права модуля. Модулю требуются Deckhouse 1.76 и log-shipper 1.0.6 или новее.

Ключевые изменения

Изменения в этом релизе:

  • Каждый источник логов читается на узле один раз независимо от числа кодов событий.
  • События, не прошедшие проверку по реестру событий, отбрасываются, а плагины обогащения заполняют целевые поля.
  • Кастомные ресурсы и настройки модуля ограничены схемой, права компонентов сужены, а поля назначений, которые могут содержать секреты, скрыты от пользователей без доступа к ним.
  • Кластерный шиппер собирает логи подов из указанных в нём неймспейсов, а селектор неймспейсов может одновременно включать и исключать неймспейсы.
  • Для назначения, которое отправляет события в формате CEF, можно задать версию формата в префиксе заголовка.

Новый функционал

В этом релизе добавлено:

  • Алерт D8SecurityEventsManagerAgentDeliveryStalled срабатывает, если у агента log-shipper есть недоставленные события безопасности и за 10 минут он не доставил в шлюз ни одного из них. Раньше такая задержка не вызывала алертов, а поды шлюза оставались в состоянии Ready. В алерте указаны узел и приёмник.
  • Параметр input.kubernetesPods.namespaceSelector принимает matchNames и excludeNames одновременно: исключение применяется после включения. Раньше можно было задать только один из списков.
  • Параметр encoding.cef.version в ClusterSecurityEventDestination задаёт версию формата CEF: V0 записывает префикс CEF:0 и используется по умолчанию, V1 записывает CEF:1. Поля заголовка и расширения не меняются. Параметр доступен для назначений типов Kafka, Vector, File, Console и Socket.
  • Параметр spec.cef.version в ClusterSecurityEventConfig задаёт версию формата CEF для всего кластера. Параметр encoding.cef.version назначения имеет приоритет над ним.
  • В DKP 1.78 и новее при включённом модуле multitenancy-manager ресурсы SecurityEventDefinition и ClusterSecurityEventEnrichmentPlugin регистрируются как кластерные ресурсы, доступ к которым можно выдавать. По умолчанию оба ресурса доступны всем проектам. Чтобы ограничить доступ к ним, используйте ClusterResourceGrantPolicy.

Улучшения

В этом релизе улучшено:

  • Конфигурации сбора и назначения создаются на элемент шиппера, а не на код события. Раньше источник логов с 50 кодами событий читался на каждом узле 50 раз и требовал отдельного дискового буфера на каждый код — до 20 ГиБ на узел. События по-прежнему фильтруются на узле.
  • Все назначения используют один Secret с TLS в неймспейсе d8-log-shipper вместо копии на каждый код события.
  • Шлюз определяет код события по тем же правилам extract, что и агент. Строка лога, которая соответствует нескольким кодам событий, порождает событие для каждого из них.
  • Если элемент шиппера содержит правило, которое нельзя преобразовать в фильтр на узле, логи элемента отправляются в шлюз без фильтрации и обрабатываются там. Это исключает отбрасывание событий на узле.
  • Конфигурации сбора и назначения, созданные прежними версиями модуля, удаляются после того, как готовы новые.

Исправления

В этом релизе исправлено:

  • Подключения агентов log-shipper к шлюзу больше не завершаются ошибкой SSL alert number 80. Ошибка возникала примерно при каждом втором переподключении и задерживала доставку событий.
  • Плагины обогащения k8s-pod-info, k8s-container-info и k8s-nodeuser-info снова заполняют целевое поле. Начиная с версии 1.0.2 плагины оставляли поле пустым, а в логе шлюза была ошибка cjson unavailable: поля actor.id, object.name и object.namespace событий внешних модулей и имена статических пользователей не заполнялись. Если библиотеку разбора JSON не удаётся загрузить, причина теперь записывается в лог шлюза.
  • Если в ClusterSecurityEventDestination задан один параметр encoding.cef, остальные параметры больше не получают встроенные значения. Раньше deviceVendor, deviceProduct и deviceVersion получали значения по умолчанию и переопределяли spec.cef из ClusterSecurityEventConfig.
  • Если несколько объектов SecurityEventDefinition объявляют один и тот же код события и источник, шлюз использует определение, имя которого идёт первым по алфавиту. Раньше критичность, категория и описание таких событий могли меняться между согласованиями. Остальные определения отражаются в метрике gateway_config_problematic_cluster_objects с проблемой duplicate_code_source.
  • Конфигурация шлюза больше не меняется между согласованиями, если в кластере несколько объектов ClusterSecurityEventConfig. Раньше порядок условий маршрутизации и источник значений по умолчанию для заголовка CEF зависели от порядка объектов в кэше API. Это приводило к лишним перезагрузкам шлюза и могло менять производителя, продукт и версию в заголовке CEF.
  • Порядок правил разбора в шлюзе больше не меняется между согласованиями. Раньше, если два правила охватывали одни и те же поды или два шиппера объявляли одинаковые источник и код события, применяемые parser или transform могли меняться.
  • Назначение cluster-loki создаётся, только если доступен CA kube-rbac-proxy. Раньше назначение могло создаваться без CA, и все события, отправленные в Loki, терялись.
  • Правила parser применяются к шипперу, который выбирает поды через input.kubernetesPods.labelSelector.matchExpressions. Раньше логи такого шиппера собирались, но не разбирались, и поля, заданные в transform, оставались пустыми.
  • Шиппер с селектором подов, который содержит только требования NotIn и DoesNotExist, охватывает поды без меток — так же, как Kubernetes и log-shipper. Раньше логи таких подов собирались, но не разбирались.
  • ClusterSecurityEventShipper с input.type: KubernetesPods и неймспейсами, заданными в input.kubernetesPods.namespace или input.kubernetesPods.namespaceSelector.matchNames, собирает события из этих неймспейсов. Раньше такой шиппер оставался в состоянии ReconcileFailed и не собирал события.
  • Контроллер больше не записывает в лог ошибки failed to remove finalizer during SED cleanup и failed to update success status, когда два согласования одновременно обрабатывают один SecurityEventDefinition. Эти ошибки не влияли на результат согласования.
  • Параметр gateway.logShipperBuffer.maxEvents применяется. Раньше он игнорировался, и буфер типа Memory использовал значение по умолчанию log-shipper.
  • Secret’ы с TLS, созданные в d8-log-shipper прежними версиями модуля, удаляются, когда на них не ссылается ни одно назначение. При удалении SecurityEventDefinition его назначение удаляется раньше Secret’ов, на которые оно ссылается. Раньше ссылка на удалённый Secret могла нарушить конфигурацию log-shipper для всех модулей кластера.
  • Изменение или удаление элемента шиппера и удаление шиппера удаляют связанный ClusterLogDestination. Раньше такие объекты оставались в кластере, обрабатывались каждым агентом log-shipper и не позволяли удалить общий Secret с TLS.
  • Шиппер, у источника которого нет SecurityEventDefinition, больше не блокирует удаление своих остальных объектов. Раньше элементы, удалённые из такого шиппера, сохраняли конфигурации сбора и продолжали собирать логи.
  • Шлюз отбрасывает события, не прошедшие проверку по реестру событий. Раньше при пороге критичности Low, который действует по умолчанию, события без подходящего SecurityEventDefinition или без обязательного поля попадали в хранилище без критичности, категории и описания, и фильтры и дашборды по критичности их не показывали. При таком отбрасывании срабатывает алерт D8SecurityEventsManagerGatewayEventRegistryDrops.

Обновления безопасности

Обновления безопасности в этом релизе:

  • Поля назначений, которые могут содержать секреты, помечены x-kubernetes-sensitive-data: true: токен и пароль аутентификации назначений http, loki и elasticsearch, пароль SASL для Kafka, токен Splunk HEC и значения spec.http.headers. В Deckhouse 1.76 и новее эти поля удаляются из ответов get, list и watch для пользователей без доступа к субресурсу clustersecurityeventdestinations/sensitive и маскируются в журнале аудита. В Deckhouse 1.77 и новее они также маскируются в ответах create, update и patch. Если не включён параметр controlPlaneManager.encryptionEnabled, значения хранятся в etcd в открытом виде, поэтому используйте поля tokenSecretRef и passwordSecretRef.
  • Поставляемое назначение cluster-loki проверяет сертификат и имя узла Loki. Раньше в версиях Deckhouse ниже 1.76 проверка была отключена, что позволяло подменить Loki из сети кластера.
  • Все поля кастомных ресурсов и настроек модуля, которые задаёт пользователь, имеют явные ограничения: maxLength для строк, maxItems для массивов, maxProperties для карт, minimum и maximum для чисел.
  • Поля SecurityEventDefinition.spec.code и produces[].eventCode обоих типов шипперов должны соответствовать формату ^[A-Z0-9_]+$. Раньше объекты с другими кодами принимались и игнорировались. Теперь такие объекты отклоняются при создании и при изменении spec.
  • ClusterRole контроллера больше не предоставляет кластерный доступ к secrets и events. Доступ к Secret’ам ограничен неймспейсом модуля и d8-log-shipper, а запись в неймспейсе модуля — Secret’ами gateway-vector-config и gateway-destination-cas. Контроллер больше не изменяет Secret’ы, которыми владеет пользователь.
  • Сайдкар перезагрузки конфигурации шлюза и сайдкар enrichment-cache отдают метрики только на loopback-адресах: 127.0.0.1:9256 и 127.0.0.1:9261. Порты 9255 и 9260, доступные из сети кластера, обслуживают только пробы. Prometheus собирает метрики через kube-rbac-proxy.
  • Service controller больше не публикует порт 8081 проб.
  • Объекты RBAC переименованы и содержат имя компонента: d8:security-events-manager:controller:rbac-proxy, d8:security-events-manager:aggregator:rbac-proxy, d8:security-events-manager:gateway:rbac-proxy, d8:security-events-manager:gateway:pod-reader, а также d8:security-events-manager:controller:log-shipper-secrets для Role и RoleBinding в d8-log-shipper.

Несовместимые изменения

Изменения, влияющие на обратную совместимость:

  • Модулю требуется log-shipper версии 1.0.6 или новее.
  • Минимальная поддерживаемая версия Deckhouse — 1.76. На более ранних версиях модуль не устанавливается.
  • Имя неймспейса в input.kubernetesPods.namespaceSelector и input.kubernetesPods.namespace должно быть корректной меткой DNS-1123. Раньше некорректные имена принимались и нарушали сбор логов для всего шиппера.
  • Поле input.kubernetesPods.labelSelector.matchLabels не может быть пустым. Раньше пустое matchLabels принималось, и логи собирались из всех неймспейсов, не порождая событий.
  • Требование в input.kubernetesPods.labelSelector.matchExpressions должно содержать непустой key, содержать values для операторов In и NotIn и не содержать values для операторов Exists и DoesNotExist. Раньше такие требования принимались, и шиппер оставался в состоянии ReconcileFailed.
  • Настройки модуля ограничены схемой: у replicas заданы минимальное и максимальное значения, а значения CPU и памяти должны быть записаны в обычном или суффиксном формате величин Kubernetes. Экспоненциальная запись, например 128e6, отклоняется. ModuleConfig, не соответствующий схеме, блокирует обновление модуля.
  • Поле SecurityEventDefinition.spec.metadata принимает только docs.desc.{en,ru} и tests.{executionTarget,testability,trigger.commands,trigger.cleanupCommands}. Остальные ключи удаляются при следующей записи объекта.

Рекомендации по обновлению

Перед обновлением учтите следующее:

  • Перед обновлением модуля обновите Deckhouse до версии 1.76 или новее.
  • Перед обновлением модуля обновите log-shipper до версии 1.0.6 или новее. С более ранней версией log-shipper модуль сохраняет прежнюю схему сбора.
  • Перед обновлением сверьте с новыми схемами ModuleConfig, собственные объекты SecurityEventDefinition с другими ключами в spec.metadata и кастомные ресурсы с длинными регулярными выражениями, grok-шаблонами, путями полей или значениями HTTP-заголовков. Поставляемые назначение и определения событий соответствуют новым схемам.
  • Перед обновлением проверьте шипперы на имена неймспейсов и требования matchExpressions, которые отклоняет новая схема. Существующие объекты с такими значениями не удаляются, но любое их изменение отклоняется, пока значения не исправлены.
  • Найдите объекты SecurityEventDefinition и шипперы с кодами событий, которые не соответствуют формату ^[A-Z0-9_]+$. Такие объекты игнорируются, а любое изменение их spec отклоняется.
  • Чтобы читать учётные данные, заданные в назначении значением, выдайте доступ get, list или watch к субресурсу clustersecurityeventdestinations/sensitive. У контроллера модуля и роли d8:security-events-manager:admin-kubeconfig этот доступ уже есть.
  • Добавьте метку security-events-manager.deckhouse.io/credential-secret к созданным вручную Secret’ам с учётными данными назначений правил алертов. Контроллер больше не добавляет эту метку. У Secret’а, поставляемого с модулем, она уже есть.
  • Чтобы назначения, созданные до обновления, использовали spec.cef из ClusterSecurityEventConfig, удалите из их encoding.cef параметры deviceVendor, deviceProduct и deviceVersion. Значения, записанные прежними версиями, остаются в объектах.
  • После обновления возможно однократное дублирование событий из собираемых файлов логов: каждый файл читается заново с начала текущей ротации.
  • После обновления события, не прошедшие проверку по реестру событий, не попадают в хранилище. Если сработал алерт D8SecurityEventsManagerGatewayEventRegistryDrops, найдите отброшенный код события по строке enforce_event_registry: dropped в логе контейнера vector шлюза и убедитесь, что источник заполняет поля, которые SecurityEventDefinition объявляет обязательными.

Документация

Изменения в документации:

  • На странице примеров приведён ClusterSecurityEventShipper, который собирает логи подов из указанных неймспейсов, в том числе с одновременно заданными matchNames и excludeNames.
  • Пример SecurityEventLoggingTransformationRules размещён в неймспейсе d8-runtime-audit-engine, где работает ссылающийся на него шиппер. На странице также указано, что поле spec.selector этих правил не используется для выбора подов.
  • В примерах с плагином k8s-pod-info имя пода и неймспейс задаются через @root.pod и @root.namespace. Прежние примеры использовали поля, которых нет в событиях.
  • Примеры с Falco выбирают поды по метке app: runtime-audit-engine в неймспейсе d8-runtime-audit-engine. Прежние примеры использовали метку, которой нет у подов модуля.
  • Описан синтаксис пути в transform[].value и enrich[].args[].value, в том числе скобки и кавычки для ключей, содержащих точку. Примеры с Falco исправлены в соответствии с ним.

v1.1.5

Дата релиза: 2026-09-07

Обновления безопасности образов alert-evaluator, controller и go-hooks: обновлены зависимости, устраняющие известные уязвимости, а OpenVEX-аттестации помечают неиспользуемые пакеты golang.org/x/crypto как not affected.

Ключевые изменения

Изменения в этом релизе:

  • В образах alert-evaluator, controller и go-hooks обновлены библиотеки golang.org/x, чтобы устранить уязвимости уровней High и Critical, выявленные при сканировании образов.
  • OpenVEX-аттестации для controller и module bundle помечают уязвимости в golang.org/x/crypto/ssh и golang.org/x/crypto/openpgp как not affected, потому что эти пакеты не используются.

Обновления безопасности

Обновления безопасности в этом релизе:

  • В образе alert-evaluator обновлены golang.org/x/net до v0.56.0, golang.org/x/text до v0.39.0 и golang.org/x/sys до v0.46.0. Обновление устраняет связанные CVE, в том числе CVE-2025-47911, CVE-2025-58190, CVE-2026-25680, CVE-2026-25681, CVE-2026-27136, CVE-2026-33814, CVE-2026-39821, CVE-2026-39824, CVE-2026-42502, CVE-2026-42506, CVE-2026-46600 и CVE-2026-56852.
  • В образах controller и go-hooks обновлён golang.org/x/crypto до v0.55.0. Обновление устраняет уязвимость Critical CVE-2026-56854.
  • OpenVEX-утверждения для controller и module bundle помечают CVE-2026-56855, CVE-2026-78662 и GO-2026-5932 как not_affected с обоснованием vulnerable_code_not_in_execute_path. Controller использует golang.org/x/crypto для bcrypt, scrypt и pbkdf2 через sprig; go-hooks — для ocsp и pkcs12 через cfssl. Ни один из компонентов не импортирует golang.org/x/crypto/ssh и golang.org/x/crypto/openpgp.

v1.1.4

Дата релиза: 2026-09-03

Правила алертинга теперь на LogQL и вычисляются напрямую по Loki: ClusterSecurityEventAlertRule переработан по образцу PrometheusRule (группы правил с alert/expr/for/labels/annotations), конвейер алертинга больше не проходит через Vector.

Ключевые изменения

Изменения в этом релизе:

  • ClusterSecurityEventAlertRule теперь устроен как PrometheusRule: spec.groups[].rules[], у каждого правила — alert, for, severityLevel, labels, annotations, а также либо написанный вручную LogQL-запрос expr, либо структурированный блок match/aggregation (коды событий, источники, категории, инициаторы, группировка, порог), который компилируется в эквивалентный LogQL. Это несовместимое изменение спецификации ресурса — перепишите существующие правила перед обновлением.
  • Каждое правило объявляет свою форму в обязательном поле mode (Expr или Match), которое должно совпадать с заполненным блоком. Веб-интерфейс платформы по полю mode показывает только поля выбранной формы.
  • Новый компонент alert-evaluator работает внутри существующего Deployment aggregator, вычисляет LogQL-запрос каждого правила по Loki кластера по расписанию и публикует сработавшие правила через ту же метрику security_events_alert_last_firing_timestamp_seconds, что и раньше. Штатный алерт D8SecurityEventAlertFiring не изменился.
  • gateway больше не пересылает копию подходящих событий на aggregator по сети: alert-evaluator читает данные напрямую из Loki. TLS-материалы и процесс Vector у aggregator больше не нужны.
  • Для работы правил алертинга должен быть включён ClusterSecurityEventDestination cluster-loki — без него LogQL нечего запрашивать.

Улучшения

В этом релизе улучшено:

  • Правило теперь может смотреть сколь угодно далеко назад и группировать по любому лейблу, который поддерживает LogQL, а не только по восьми фиксированным полям из прежнего перечисления aggregation.groupBy. Для этого напишите expr вручную.
  • Каждый ClusterSecurityEventAlertRule публикует собственные status.conditions (Ready/Degraded с причиной вроде LogQLQueryError, LokiDestinationMissing или CardinalityLimitExceeded).

Несовместимые изменения

Изменения, влияющие на обратную совместимость:

  • Каждое правило в ClusterSecurityEventAlertRule.spec.groups[].rules[] должно объявлять mode: Expr или mode: Match — в соответствии с заполненным блоком (expr или match). Правило без mode или с mode, расходящимся с блоком, отклоняется.
  • Старые поля spec.match/spec.aggregation/spec.alert (одно правило на объект) удалены. Перепишите каждое правило в spec.groups[].rules[]: используйте либо написанный вручную LogQL-запрос expr, либо те же поля match/aggregation, что и раньше (eventCodes, sources, categories, severityMin, actorType, actors, excludeActors, excludeSystemActors, groupBy, threshold, window), теперь вложенные в каждое правило. Примеры приведены в документации модуля.
  • API-сервер теперь проверяет ограничения полей у ClusterSecurityEventShipper, PodSecurityEventShipper, ClusterSecurityEventLogTransformation, SecurityEventLogTransformation, SecurityEventDefinition, ClusterSecurityEventEnrichmentPlugin и ClusterSecurityEventDestination, которые раньше не проверялись. Пустой селектор меток (labelSelector: {} / selector: {}) теперь отклоняется вместо выбора всех объектов, значение spec.*.buffer.maxEvents у ClusterSecurityEventDestination должно быть не меньше 100, а ряд текстовых полей больше не принимает пустую строку.
  • Для вычисления правил алертинга требуется ClusterSecurityEventDestination cluster-loki (включите его через securityEventConfig.destinations). Без него каждый ClusterSecurityEventAlertRule находится в состоянии Degraded, и ни одно правило не вычисляется; сбор и доставка событий в остальные destinations не затрагиваются.

Рекомендации по обновлению

Перед обновлением учтите следующее:

  • При переписывании правила добавьте mode: Expr правилу с написанным вручную expr или mode: Match правилу, собранному из match/aggregation.
  • Перед обновлением сохраните все существующие ClusterSecurityEventAlertRule (d8 k get clustersecurityeventalertrule -o yaml). После обновления перепишите каждое правило в новом виде spec.groups[].rules[] — старые поля верхнего уровня спецификации отклоняются обновлённой схемой CRD.
  • Перед обновлением проверьте существующие ресурсы на соответствие новым ограничениям: выполните d8 k get clustersecurityeventshipper,podsecurityeventshipper,clustersecurityeventlogtransformation,securityeventlogtransformation,clustersecurityeventdestination -o yaml и найдите пустые labelSelector/selector или buffer.maxEvents меньше 100. Существующий объект, нарушающий ограничение, продолжает работать, но следующая запись в него отклоняется.
  • Прежде чем полагаться на правила алертинга, убедитесь, что включён cluster-loki (securityEventsManager.securityEventConfig.destinations содержит cluster-loki) — иначе каждое правило остаётся в состоянии Degraded.

Известные ограничения

Известные ограничения этого релиза:

  • Состояние вычисления (pending/firing) хранится в памяти процесса alert-evaluator: его перезапуск сбрасывает отсчёт for для каждого правила.
  • Группировка по LogQL-лейблу с неограниченной кардинальностью ограничена 500 наборами лейблов на правило: остальные отбрасываются, и правило помечается CardinalityLimitExceeded, но продолжает срабатывать для уже отслеживаемых групп.

Документация

Изменения в документации:

  • Раздел про алертинг на странице примеров переписан под ресурс в стиле PrometheusRule и описывает форму expr и форму match/aggregation, включая line filter, воспроизводящий прежнее поведение excludeSystemActors.

v1.1.3

Дата релиза: 2026-08-27

Исправления безопасности в образах модуля: OpenVEX-аттестации помечают golang.org/x/crypto GO-2026-5932 как not affected для controller и go-hooks в module bundle.

Ключевые изменения

Изменения в этом релизе:

  • Образы модуля публикуют OpenVEX-аттестации, чтобы CVE-скан подавлял GO-2026-5932 там, где openpgp не на пути выполнения.

Обновления безопасности

Обновления безопасности в этом релизе:

  • Добавлены OpenVEX-утверждения для GO-2026-5932 (golang.org/x/crypto/openpgp) для controller и module bundle (go-hooks), статус not_affected / vulnerable_code_not_in_execute_path.
  • В сборку модуля подключена cosign OpenVEX-аттестация, чтобы CI CVE-скан читал утверждения из OCI registry.

v1.1.2

Дата релиза: 2026-08-27

Алертинг по событиям безопасности: новый ресурс ClusterSecurityEventAlertRule считает подходящие события по ключу в течение временного окна и поднимает обычный алерт Prometheus, как только достигнут порог. Добавлен тип назначения Http для вебхуков и HTTP-коллекторов и новое событие о нарушении целостности в containerd.

Ключевые изменения

Изменения в этом релизе:

  • Новый ресурс ClusterSecurityEventAlertRule: в нём описывается, за какими событиями следить, как их считать и что должно быть написано в алерте.
  • Сработавшее правило поднимает алерт Prometheus D8SecurityEventAlertFiring, поэтому он становится объектом ClusterAlert, виден в консоли рядом со всеми остальными алертами, сохраняет историю и уходит по штатной доставке алертов кластера. Доставку настраивать не нужно.
  • Новый тип назначения Http отправляет события безопасности на любой HTTP-эндпоинт — вебхук или HTTP-коллектор — с аутентификацией, TLS, произвольными заголовками и выбором способа упаковки тела запроса.
  • Новое событие безопасности D8_CONTAINERD_INTEGRITY_VIOLATION сообщает о непройденной проверке целостности в containerd — чаще всего об образе, которому отказано при загрузке из-за неверной подписи.

Новый функционал

В этом релизе добавлено:

  • ClusterSecurityEventAlertRule (кластерный ресурс, короткое имя csear). spec.match отбирает события по коду, минимальной критичности, категории, компоненту-источнику, актору и типу актора; spec.aggregation группирует их по groupBy и срабатывает, как только группа достигает threshold в пределах window; spec.alert несёт краткое и подробное описание, дополнительные лейблы и уровень критичности DKP severityLevel. Правило без блока aggregation алертит на каждое подходящее событие.
  • match.excludeSystemActors (включён по умолчанию) убирает из правила системные личности по тому же списку, что и фильтр «Исключить системные» в консоли. Штатная работа кластера доминирует в потоке событий: на простаивающем кластере один ServiceAccount DKP дал 2617 из 2812 чтений секретов за час, — так что без него первое же написанное правило оказывается алертом про платформу. Для всего, что встроенный список не покрывает, есть match.excludeActors и match.actors — глобы, сравниваемые с actor.id.
  • Алерт гаснет сам примерно через пять минут после последнего срабатывания правила. Настраивать нечего: агрегатор публикует security_events_alert_last_firing_timestamp_seconds — момент последнего срабатывания, — а D8SecurityEventAlertFiring смотрит на его давность. Метрика отдаётся на эндпоинте агрегатора /alert-metrics/metrics и годится для дашбордов.
  • Новый тип назначения Http: spec.http.endpoint, опциональные auth, tls и headers, а также framing — JSONArray (по умолчанию) для приёмников, ожидающих один документ на запрос, и NewlineDelimited для коллекторов, читающих NDJSON. Число попыток доставить один набор событий ограничено, поэтому приёмник, раз за разом отклоняющий запрос, который никогда не примет, не задерживает остальную очередь: когда попытки заканчиваются, набор отбрасывается в метрики ошибок sink’а, по которым у модуля уже есть алерт.
  • Новое событие безопасности D8_CONTAINERD_INTEGRITY_VIOLATION (категория Runtime, критичность High, источник containerd-integrity). Оно возникает, когда containerd отказывает образу с непройденной проверкой подписи, а также когда контрольная сумма файла на узле не совпадает с ожидаемой. В object.name попадает ссылка на образ, в object.namespace — пространство имён, в которое он загружался, в metadata.extra — сообщение, путь к файлу и ожидаемый и фактический хеши, если событие их содержит. Собирается только на узлах с cri ContainerdV2 в редакции CSE; трафик проб d8-upmeter отфильтровывается.
  • События kube-audit теперь несут actor.sourceIP — адрес исходного клиента, взятый из начала цепочки запроса, — рядом с полной цепочкой actor.sourceIPs. По нему можно группировать в правилах (ActorSourceIP): именно так правило про неавторизованные запросы опознаёт клиента, когда группировать не по чему.
  • В модуле появился отдельный однорепличный компонент alert-aggregator, который держит счётчики, и свой алерт D8SecurityEventsManagerAggregatorNotAvailable. Пока он недоступен, сбор и доставка событий продолжаются — события ждут в буфере gateway, — но окна подсчёта начинаются заново, поэтому частично набранный порог считается с нуля.

Улучшения

В этом релизе улучшено:

  • В путях трансформаций можно адресовать элементы массива, например sourceIPs[0]. Раньше каждый сегмент пути считался ключом map, поэтому любое поле-массив в логе было невозможно отобразить.
  • Документация модуля, CRD и OpenAPI-схемы теперь попадают в bundle- и release-образы.

Рекомендации по обновлению

Перед обновлением учтите следующее:

  • Менять конфигурацию не требуется. Компоненты алертинга создаются при обновлении и простаивают, пока не появится первый ClusterSecurityEventAlertRule. alert-aggregator по замыслу работает в одной реплике со стратегией Recreate — счётчики живут в одном процессе, — поэтому его обновления и вытеснение с узла дают короткий перерыв в подсчёте.

Известные ограничения

Известные ограничения этого релиза:

  • Правило видит только то, что записывает политика аудита кластера. Политика DKP по умолчанию логирует list секретов, но не get одного секрета по имени, и отбрасывает большинство запросов от system:authenticated, поэтому правило на K8S_SECRET_ACCESSED не увидит d8 k get secret <name>. Прежде чем делать вывод, что правило не работает, посмотрите политику аудита.
  • Счётчики живут в памяти агрегатора. Его рестарт начинает каждое окно с нуля.
  • Группировка по значению с неограниченной кардинальностью ограничена: после 500 различных значений лейбл отбрасывается, а алерт всё равно срабатывает — только без одного измерения.
  • На кластерах с включённым update.blockOnAlerts в модуле deckhouse алерт с уровнем не выше настроенного порога (по умолчанию 4) блокирует применение релизов DKP, пока он горит. Значение severityLevel по умолчанию — 6 — под порог не попадает; понижайте его осознанно.

Документация

Изменения в документации:

  • На странице примеров появился раздел про алертинг с отдельным правилом на каждый сценарий обнаружения: повторные exec в поды от одного актора, всплеск правок RBAC с группировкой по актору и пространству имён, неавторизованные запросы с группировкой по адресу клиента и нарушение целостности containerd как случай, когда достаточно одного события. Там же добавлен пример HTTP-назначения.

v1.0.5

Дата релиза: 2026-08-24

Исправления безопасности в образах модуля: обновлены Go-зависимости batch-хуков и связанных компонентов для устранения известных CVE.

Ключевые изменения

Изменения в этом релизе:

  • В образы модуля включены обновления зависимостей, закрывающие известные CVE в Go-компонентах.

Обновления безопасности

Обновления безопасности в этом релизе:

  • В hooks/batch и связанных Go-образах подняты golang.org/x/net и golang.org/x/text для устранения CVE.
  • В образы компонентов включены исправления безопасности, связанные с CVE.

v1.0.4

Дата релиза: 2026-08-18

Исправлен дедлок обновления: контроллер не мог опубликовать конфиг gateway, а Deployment gateway не мог раскатиться.

Ключевые изменения

Изменения в этом релизе:

  • Контроллер снова может публиковать конфиг Vector для gateway — его собственная валидация никогда не могла завершиться на реальных кластерах.
  • Deployment gateway теперь раскатывается на кластерах, где системных узлов столько же, сколько реплик, а не застревает на поде в Pending.
  • Назначение с нерезолвящимся credential больше не роняет весь конфиг gateway.
  • Метрики reloader’а переименованы, чтобы не пересекаться с метриками log-shipper.

Улучшения

В этом релизе улучшено:

  • Новый параметр controller.vectorValidateTimeout (по умолчанию 60s) — таймаут запуска vector validate, который контроллер выполняет перед публикацией конфига gateway.
  • Новые алерты: D8SecurityEventsManagerControllerConfigNotPublished, D8SecurityEventsManagerDestinationCredentialMissing и D8SecurityEventsManagerControllerValidateUnavailable. Раньше контроллер мог сколь угодно долго не публиковать конфиг, и ни один алерт при этом не срабатывал.

Исправления

В этом релизе исправлено:

  • Контроллер больше не замораживает опубликованный конфиг gateway. Его шаг vector validate выполнялся с таймаутом 10s в контейнере с лимитом 64Mi и погибал либо по дедлайну, либо от OOM, а сбой трактовался как вердикт «конфиг невалиден» — из-за чего Secret навсегда оставался на прежней ревизии. Теперь валидация запускается с --no-environment (около 2 секунд вместо 5 на конфиге в 256 КБ, без построения топологии и походов по сети), пол по памяти контейнера — 192Mi, таймаут по умолчанию — 60s, а невозможность выполнить проверку больше не блокирует публикацию: конфиг в любом случае валидирует reloader в gateway.
  • Deployment gateway использует maxSurge: 0 / maxUnavailable: 1. При стандартном surge обновление gateway с двумя репликами запрашивало третий под, а обязательная anti-affinity по узлу оставляла его в Pending навсегда на кластере с двумя системными узлами: модуль рапортовал Deployed, продолжая работать на предыдущем образе.
  • ClusterSecurityEventDestination, объявивший credential, который контроллер не смог зарезолвить, теперь блокирует публикацию и сообщает конкретное назначение и поле, вместо того чтобы отдать блок auth без токена. Vector такой блок не принимает, из-за чего весь конфиг gateway переставал загружаться и доставка прекращалась во все назначения сразу, а не только в проблемное. Покрыты Loki, Elasticsearch, Splunk HEC и Kafka SASL.
  • auth.strategy: None (значение по умолчанию в CRD) больше не попадает в сгенерированный конфиг как {"strategy": "none"}, которое Vector не принимает.
  • У Deployment контроллера появился nodeSelector на system-узлы; раньше его не было вовсе, и контроллер мог уехать на worker-узел.
  • CI-тест валидации Vector проверяет тот defaults.json, который реально едет в образе gateway, а не написанный вручную аналог.

Несовместимые изменения

Изменения, влияющие на обратную совместимость:

  • Метрики reloader’а переименованы с префиксом security_events_manager_gateway_: vector_config_validation_error, vector_config_apply_failures_total, vector_config_periodic_retry_attempts_total, vector_config_reloads_success_total, vector_config_last_reload_success_timestamp_seconds, reloader_validate_duration_seconds, reloader_validate_timeout_seconds, reloader_apply_duration_seconds, reloader_vector_restarts_total, reloader_fsnotify_events_total. Старые имена совпадали с метриками vector-reloader из log-shipper, чьи правила не фильтруют по namespace, поэтому проблемы этого модуля поднимали алерт D8LogShipperConfigInvalid. Правила, дашборды и документация модуля обновлены; собственные recording-правила, алерты и панели на старых именах нужно поправить.
  • Переменная окружения CONTROLLER_VECTOR_VALIDATE_SKIP_ABOVE_BYTES удалена. Её порог в 256 КиБ находился чуть выше реального размера конфига, из-за чего валидация могла пропускаться случайно, а не намеренно; случай, ради которого она вводилась, теперь покрыт поведением fail-open.
  • В версии v1.0.3 значение minimalSeverity по умолчанию сменилось с Medium на Low без записи в release notes. Кластеры, обновляющиеся с v1.0.0 и ранее, отправляют заметно больше событий, что накладывается на дисковые буферы по умолчанию, появившиеся в той же версии. Если нужен прежний объём, задайте значение явно.

Рекомендации по обновлению

Перед обновлением учтите следующее:

  • Пол по памяти контейнера контроллера поднимается с 64Mi до 192Mi (потолок VPA — с 256Mi до 512Mi). Столько нужно vector validate, чтобы отработать вообще; ниже контейнер убивает OOM прямо посреди валидации.

v1.0.3

Дата релиза: 2026-08-17

Настройка буферов gateway, плагины обогащения, SecretRef для назначений, CEF/Socket sink и усиление безопасности API Vector и RBAC контроллера.

Ключевые изменения

Изменения в этом релизе:

  • Настраиваемые Disk-буферы для слоёв gateway и log-shipper, с переопределением на назначение.
  • Плагины обогащения (k8s-pod-info, k8s-container-info, k8s-nodeuser-info) через ClusterSecurityEventEnrichmentPlugin.
  • Учётные данные назначений можно брать из Secret вместо открытого текста в CR.
  • Кодирование CEF и назначения Socket для интеграции с SIEM.
  • API gateway на loopback; ужесточены RBAC для Secret и проверка SSRF для enrichment endpoint.

Новый функционал

В этом релизе добавлено:

  • Параметры буфера gateway.buffer и gateway.logShipperBuffer в значениях модуля; переопределение через spec.buffer в ClusterSecurityEventDestination; по умолчанию Disk + Block; maxSize — Kubernetes quantity с суффиксом единицы (например 512Mi).
  • Событие K8S_ADMISSION_POLICY_DENIED для отказов admission-policy-engine в audit-логе Kubernetes.
  • CRD ClusterSecurityEventEnrichmentPlugin для встроенных Internal enrichment-плагинов сайдкара enrichment-cache (External в схеме есть, в контроллере пока нет).
  • Плагины обогащения k8s-pod-info, k8s-container-info и k8s-nodeuser-info.
  • Поля tokenSecretRef и passwordSecretRef в ClusterSecurityEventDestination для Loki, Elasticsearch, Kafka SASL и Splunk HEC; встроенный cluster-loki хранит токен в Secret.
  • Кодирование CEF для Kafka, Vector, File и Console (encoding.codec: CEF), опциональная syslog-обёртка и метаданные CEF через spec.cef / значения модуля.
  • Тип назначения Socket (TCP/UDP/Unix) для CEF-over-syslog в SIEM.

Исправления

В этом релизе исправлено:

  • Исправлен алерт D8SecurityEventsManagerControllerReconcileErrorsHigh.
  • Параметр gateway.reloaderValidateTimeout задаёт таймаут vector validate (по умолчанию 120s).
  • TLS Secret в d8-log-shipper удаляются вместе с SecurityEventDefinition.
  • Ошибки разрешения credential Secret пишутся в warning с путём поля.
  • Watcher credential Secret фильтрует по лейблу security-events-manager.deckhouse.io/credential-secret: true.
  • Reloader SaveTo() пишет конфиг Vector с правами 0600.
  • resolveDestinationSecretRefs() возвращает глубокую копию объекта CSED.
  • Lua extractJSON возвращает nil и пишет ошибку, если cjson недоступен.
  • В комментарии enrichment-cache исправлен порт (9260 → 9261).
  • E2E-триггеры для K8S_CLUSTERROLEBINDING_DELETED и K8S_CONFIGMAP_MODIFIED создают тестовый namespace и учитывают 404 при удалении CRB.
  • Ресурсы контроллера получают лейбл heritage: deckhouse.

Обновления безопасности

Обновления безопасности в этом релизе:

  • Устранены CVE в образах модуля.
  • API gateway Vector слушает только 127.0.0.1:8686; порт 8686 убран из Service.
  • Приватный ключ mTLS-клиента хранится в Secret в d8-log-shipper, а не в ClusterLogDestination.
  • RBAC Secret ограничен неймспейсами d8-security-events-manager и d8-log-shipper.
  • CEL блокирует SSRF для spec.endpoint.url в ClusterSecurityEventEnrichmentPlugin.
  • Secret gateway-vector-config помечен security.deckhouse.io/contains-credentials: true.

Несовместимые изменения

Изменения, влияющие на обратную совместимость:

  • Форма enrich в shipper: plugin — свободная строка; args — упорядоченный массив {key,value}; имена плагинов с дефисами (k8s-pod-info). Старые CR с прежней формой не парсятся; Plugin-обогащение раньше не работало.
  • spec.splunkHEC.token необязателен при заданном tokenSecretRef.
  • CEL запрещает одновременное использование inline token/password и соответствующих *SecretRef в ClusterSecurityEventDestination.

v1.0.0

Дата релиза: 2026-06-26

Первичный релиз модуля security-events-manager.

Ключевые изменения

Изменения в этом релизе:

  • Первый публичный релиз модуля.