Релизы

v0.6.9

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

События безопасности для security-events-manager; выбор места хранения отчётов о сканировании; настраиваемые ресурсы, ограниченные повторы и алерт для сканирования узлов; ограничительная политика безопасности подов для неймспейса модуля; исправления проверки уязвимых образов при создании ресурсов и сканирования образов из частных реестров.

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

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

• Если включён модуль security-events-manager, модуль отправляет ему события безопасности о найденных при сканировании уязвимостях, секретах, нарушениях конфигурации и RBAC, об образах, отклонённых при создании ресурсов, и об ошибках сканирования реестров.
• Отчёты о сканировании можно хранить в etcd вместо security-storage: для этого задайте новому параметру securityStorageForReports значение false.
• Сканированию узлов, которому не хватает памяти или времени, можно выделить больше ресурсов; оно больше не перезапускается бесконечно, а узел, оставшийся без отчёта, вызывает алерт.
• Поды модуля работают под ограничительной политикой безопасности подов (restricted), если admission-policy-engine поддерживает исключения из политик.
• denyVulnerableImages учитывает allowedSeverityLevels, а образы из реестров с сертификатом частного CA, из небезопасных реестров и доступных через прокси кластера сканируются при включённом useVEXFromOCI.

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

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

• Параметр nodeScanning.resources задаёт запросы и лимиты CPU и памяти для заданий сканирования узлов (поды scan-noderootfs). Раньше они были фиксированными — запросы 100m/256Mi и лимиты 1/2Gi, а scanJobResources на эти задания не влияет. Каждое незаданное поле сохраняет прежнее значение, поэтому в кластере без этой настройки узлы сканируются как раньше, а запрос по умолчанию, превышающий заданный лимит, уменьшается до лимита. ModuleConfig, в котором явно заданный запрос больше лимита, не сохраняется.
• Добавлен алерт NodeVulnerabilityScanFailed (S6). Он указывает узел, оставшийся без отчёта об уязвимостях из-за неудачного сканирования файловой системы, и причину последней неудачи, например OOMKilled, DeadlineExceeded или OutOfmemory. Алерт срабатывает, если три сканирования узла подряд завершились неудачей и состояние держится пять минут. Чтобы устранить причину, увеличьте nodeScanning.resources или nodeScanning.timeout, исключите узел через nodeScanning.nodeSelector или задайте новое значение аннотации повторного сканирования trivy-operator.aquasecurity.github.io/node-rootfs-scan на узле. Неудачи также экспортируются в метрику d8_operator_trivy_node_scan_failed.
• События безопасности для модуля security-events-manager. Модуль поставляет девять ресурсов SecurityEventDefinition и ресурс PodSecurityEventShipper operator-trivy в неймспейсе d8-operator-trivy, которые создаются, только если включён security-events-manager. События создаются, когда сканирование сохраняет отчёт: уязвимости в образах рабочих нагрузок, на узлах и в образах из реестров; секреты в образах рабочих нагрузок; нарушения, найденные аудитом конфигурации и проверками инфраструктуры; нарушения RBAC; невыполненные требования стандартов соответствия; образы, отклонённые политикой denyVulnerableImages; ошибки registry-scanner при доступе к реестру или сканировании образа. Событие указывает просканированный объект — рабочую нагрузку, узел или образ — и содержит количество находок каждого уровня и имя отчёта. Список событий приведён на странице о сканировании на уязвимости.
• Событие безопасности об отчёте получает уровень его наиболее критичной находки: CRITICAL соответствует Critical, HIGH — High, MEDIUM — Medium, LOW и UNKNOWN — Low. Параметр securityEvents.minimumSeverity задаёт наименьший уровень, при котором создаётся событие, и по умолчанию равен HIGH, поэтому отчёт только с находками уровней MEDIUM и LOW не создаёт события, пока параметр не понижен. Отклонённые образы, ошибки сканирования реестров и невыполненные требования стандартов соответствия всегда создают событие.
• Параметр securityStorageForReports задаёт место хранения отчётов о сканировании. Значение по умолчанию true ничего не меняет: отчёты остаются в security-storage. При false отчёты хранятся в etcd, а security-storage запускается, только если задан nodeAgent.enabled. При изменении значения существующие отчёты не переносятся: модуль сканирует кластер заново, и до завершения сканирования отчёты неполные. Переключение на false удаляет диск security-storage вместе с отчётами, если не задан nodeAgent.enabled.
• Модуль записывает в Prometheus ряды динамики уязвимостей: trivy:workload_vulnerabilities:count — число уникальных уязвимостей контроллера по уровням критичности и trivy:workload_vulnerability_id:present — идентификаторы уязвимостей контроллера. По ним Deckhouse Console строит графики динамики уязвимостей. У Deployment одна история на все ревизии, а повторное сканирование больше не выглядит как исправление и повторное появление уязвимостей. Ряды и примеры запросов описаны в разделе «Метрики динамики уязвимостей» документации по сканированию.

Улучшения

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

• Строка лога оператора scan finished with findings указывает просканированный объект в ключах resourceKind, resourceNamespace и resourceName, для образов — также в ключах container, image и imageDigest, и заканчивается ключом severity с наивысшим уровнем находок. Ключи kind, namespace и name этой строки дублировались логгером job сканирования, поэтому JSON-парсер в зависимости от реализации возвращал либо отчёт, либо рабочую нагрузку. Строка также пишется для ExposedSecretReport и NodeVulnerabilityReport.
• registry-scanner пишет строку лога scan finished with findings с количеством уязвимостей каждого уровня для каждого сохранённого отчёта RegistryImageVulnerabilityReport, в котором есть уязвимости. Когда ресурс RegistryScanTarget переходит в состояние сбоя или меняется причина сбоя, компонент пишет одну строку registry scan failed с причиной и текстом условия Ready, а не строку на каждую повторную попытку. Цель, учётные данные реестра которой не удаётся прочитать или параметр tagFilter которой некорректен, теперь тоже попадает в лог; раньше о таком сбое сообщало только условие цели.
• trivy-provider пишет лог в формате JSON вместо консольного и для каждого образа, о котором сообщает как об уязвимом, пишет строку image rejected: vulnerabilities found с количеством уязвимостей каждого уровня. Сэмплирование строк лога отключено, поэтому под нагрузкой строки не отбрасываются.
• Оператор пишет в лог каждую строку: controller-runtime прореживал его production-лог и после первых ста строк с одним сообщением за секунду оставлял только одну из ста, поэтому большая часть строк с находками при аудите конфигурации всего кластера терялась. Формат строк не изменился.
• Отключение модуля или сканирования узлов во время сканирования больше не мешает завершить задание сканирования и удалить неймспейс d8-operator-trivy. Если включить модуль до того, как неймспейс удалится, модуль установится после удаления, а в его статусе будет указано, что задерживает удаление.

Исправления

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

• Сканирование файловой системы узла, завершившееся без отчёта, больше не повторяется бесконечно. Упавшее задание сканирования, например из-за нехватки памяти, заменялось новым через несколько секунд без ограничений, а неудача была видна только в логе оператора. Теперь сканирование повторяется через пять минут и прекращается после трёх неудач — до перезапуска оператора или нового значения аннотации повторного сканирования trivy-operator.aquasecurity.github.io/node-rootfs-scan на узле. Временная недоступность API-сервера неудачей не считается, а задание, отклонённое admission-вебхуком, повторяется каждые пять минут, пока вебхук его не пропустит.
• Параметр denyVulnerableImages.allowedSeverityLevels теперь действует: образ, все уязвимости которого имеют перечисленные уровни, допускается. Список применялся к копии результатов сканирования, поэтому любой образ хотя бы с одной уязвимостью отклонялся независимо от значения параметра.
• Команды kubectl get vulnerabilityreports и другие команды для отчётов без указания группы API теперь показывают актуальные отчёты на кластерах, обновлённых с версии 0.5. Раньше они показывали устаревшие отчёты, оставшиеся от этой версии.
• Модуль больше не переходит на несколько минут в состояние Error при первом включении.
• Отчёты о сканировании больше не становятся ненадолго недоступны модулю и Deckhouse Console после каждого обновления или изменения конфигурации модуля.
• Отчёты соответствия больше не показывают все проверки пройденными сразу после включения модуля или после перезапуска security-storage без постоянного диска. Такой отчёт сохранялся до следующего запуска по расписанию, до шести часов. Теперь он строится, как только появляются первые результаты сканирования, и ещё раз через десять минут, когда сканирование кластера завершится.
• При включённом параметре useVEXFromOCI для рабочей нагрузки, образ которой хранится в реестре с сертификатом частного CA, теперь создаётся VulnerabilityReport. Запрос VEX-аттестации не учитывал сертификаты из параметра additionalRegistryCA и CA реестра платформы, поэтому сканирование такой рабочей нагрузки завершалось ошибкой x509: certificate signed by unknown authority и отчёт не создавался.
• При включённом параметре useVEXFromOCI образы из реестров, указанных в параметре insecureRegistries, и образы ресурса RegistryScanTarget с insecure: true теперь сканируются без VEX-аттестаций. Аттестации запрашиваются только по HTTPS с проверкой сертификата, поэтому для рабочей нагрузки из HTTP-реестра или реестра с недоверенным сертификатом отчёт VulnerabilityReport не создавался, а сканирование реестров и проверка denyVulnerableImages завершались ошибкой для таких образов.
• Сканирование реестров и проверка denyVulnerableImages теперь работают через прокси кластера (параметр proxy конфигурации кластера) и сканируют образы из реестров, доступных только через прокси. Реестр, не указанный в параметре noProxy, теперь и в этих проверках доступен через прокси.
• Элемент параметра insecureRegistries со схемой или путём, например http://registry.example.com:5000, теперь действует и при сканировании рабочих нагрузок. Раньше такой элемент учитывала только проверка denyVulnerableImages.
• В кластере без доступа в интернет проверка denyVulnerableImages для образа с Java-пакетами больше не завершается ошибкой через три дня после запуска модуля. База уязвимостей Java теперь обновляется из реестра модуля с учётом параметра insecureDbRegistry, а не загружается из публичных реестров во время проверки.
• Образы на основе РЕД ОС сканируются на уязвимости в пакетах операционной системы. ОС такого образа не определялась, поэтому его отчёт VulnerabilityReport охватывал только зависимости приложений.
• Отчёт соответствия CIS Benchmark больше не применяет к рабочим узлам проверки управляющего слоя. Каждый узел выполнял проверки, предназначенные для master-узлов, поэтому отчёт содержал для рабочих узлов неприменимые к ним результаты.

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

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

• Поды неймспейса d8-operator-trivy работают под ограничительной политикой безопасности подов (restricted), если в кластере доступен API SecurityPolicyException модуля admission-policy-engine. Неймспейс получает метки security.deckhouse.io/pod-policy: restricted и security.deckhouse.io/enable-security-policy-check: "true". Подам node-collector, сканирования узлов (scan-noderootfs) и node-agent, которым нужен доступ к узлу, разрешено только то, что они используют, — через поставляемые модулем ресурсы SecurityPolicyException. В кластере без этого API метки неймспейса остаются прежними.
• Пока неймспейс d8-operator-trivy удаляется, работающие в нём поды не проверяются политикой безопасности подов.

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

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

• Если задан параметр denyVulnerableImages.allowedSeverityLevels, проверьте его значение до обновления: после обновления будут допускаться образы, все уязвимости которых имеют перечисленные уровни. Раньше такие образы отклонялись независимо от параметра.

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

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

• В FAQ описано, где хранятся отчёты о сканировании и как переключаться между двумя режимами хранения.
• Раздел «Источники данных об уязвимостях» документации по сканированию описывает, откуда берутся данные об уязвимостях и как обновляются базы, в том числе в закрытых окружениях.
• В обзоре модуля приведены системные требования и редакции Deckhouse, в которых доступен модуль.

v0.6.8

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

Оценка безопасности кластера и каждого пользовательского неймспейса; Grafana-дашборды уязвимостей и CIS удалены в пользу Deckhouse Console; алерты при отсутствии или устаревании базы уязвимостей Trivy; полные отчёты аудита конфигурации, соответствия и SBOM кластера; обновлены образы модуля и зависимости для устранения CVE.

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

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

• Модуль публикует оценку безопасности: ресурс ClusterSecurityScore для кластера и ресурс SecurityScore в каждом пользовательском неймспейсе, поэтому оценка неймспейса выдаётся вместе с доступом к самому неймспейсу.
• Удалены Grafana-дашборды Security / Trivy Image Vulnerability Overview и Security / CIS Kubernetes Benchmark; для обзора уязвимостей и результатов CIS Benchmark используйте Deckhouse Console.
• ClusterAlert предупреждает, если trivy-db отсутствует или старше vulnerabilityDatabaseMaxAge (по умолчанию 168h); чтобы отключить оба алерта, установите параметр vulnerabilityDatabaseMaxAge в "".
• Отчёты аудита конфигурации, соответствия и SBOM кластера (k8s-cluster) снова полные, когда отчёты отдаёт security-storage, а упавшее задание сканирования повторяется, а не оставляет нагрузку без отчёта.
• Обновлены зависимости и базовые образы для закрытия CVE.

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

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

• Оценка безопасности кластера и каждого пользовательского неймспейса. Оценка кластера лежит в ресурсе ClusterSecurityScore с именем cluster, оценка неймспейса — в ресурсе SecurityScore с именем security-score в этом неймспейсе. Оценка неймспейса выдаётся ролью d8:use:capability:module:operator-trivy:view вместе с доступом к неймспейсу, оценка кластера — ролью d8:manage:permission:module:operator-trivy:view. Неймспейс оценивается по той же формуле, что и кластер, без составляющих уровня кластера: неймспейс, по которому нет ни одного отчёта, ограничен значением 60, а неймспейс с выключенным сканированием всегда теряет весь вес составляющей покрытия. Составляющая, за которой нет отчётов, помечается полем notMeasured и исключается из расчёта, а не считается безупречным результатом.
• Оценка кластера экспортируется в Prometheus в метриках deckhouse_trivy_security_score, deckhouse_trivy_security_score_component, deckhouse_trivy_security_namespace_score_average, deckhouse_trivy_security_namespaces_total и deckhouse_trivy_security_namespaces_scanned. Оценки отдельных неймспейсов в метрики не выводятся: в большом кластере это добавило бы отдельный временной ряд на каждый неймспейс.
• В ресурсе RegistryScanTarget появился параметр spec.maxRepositories — число репозиториев, которые цикл берёт из каталога реестра, если параметр spec.repositories пуст; по умолчанию 100. Каталог читается только до этого предела, отчёты по остальным репозиториям сохраняются.
• Добавлены алерты TrivyVulnerabilityDatabaseOutdated (S6) при превышении окна актуальности trivy-db и TrivyVulnerabilityDatabaseMissing (S6, for: 30m), если в ConfigMap trivy-db-info нет пригодной метки trivy-db.updatedAt.

Улучшения

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

• Отчёты registry-scanner содержат версию сканера, которым получены. Поле scanner.version ресурса RegistryImageVulnerabilityReport оставалось пустым, поэтому по отчёту нельзя было определить выпуск Trivy.
• Обзор уязвимостей и результаты CIS Benchmark ожидаются в Deckhouse Console вместо удалённых Grafana-дашбордов.
• report-updater применяет изменённые учётные данные реестра без перезапуска: конфигурация Docker перечитывается при каждом обновлении словаря БДУ.
• report-updater сообщает в логе, для какого репозитория искались учётные данные и какие реестры перечислены в конфигурации Docker, если учётные данные не найдены и используется анонимный доступ. Конфигурация, в которой поле auth хотя бы одной записи не декодируется, считается некорректной целиком, и в сообщении об ошибке указывается эта запись.

Исправления

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

• Отчёт о соответствии, первое построение которого при старте оператора завершилось ошибкой, строится повторно через минуту, а ошибка пишется в лог и не прерывает reconcile. Раньше он ждал следующего запуска по расписанию — по умолчанию до шести часов, и после обновления модуля большая часть отчётов часто оставалась пустой на это время, потому что security-storage перезапускается вместе с оператором.
• Компонент security-storage теперь выбирает между PersistentVolumeClaim и emptyDir по параметру apiServerStorageClass. При значении false только у apiServerStorageClass его под ожидал claim, который так и не создавался, а при значении false только у storageClass создавался диск, который никто не использовал.
• Сканирование образов больше не прекращается, если в ConfigMap оператора отсутствует ключ scanJob.podTemplateContainerSecurityContext. Контекст безопасности платформы применялся к пустому значению, и job сканирования не создавались.
• Снятие лейбла security-scanning.deckhouse.io/enabled с последнего помеченного неймспейса теперь обновляет список неймспейсов, включённых в сканирование образов. Список не сбрасывался, поэтому оператор держал такой неймспейс в области сканирования до следующего перезапуска Deckhouse. Список также упорядочен, поэтому перестановка тех же неймспейсов больше не перезапускает оператор.
• Сканирование образов больше не возобновляется в неймспейсе, вышедшем из области сканирования. Даже с обновлённой областью список неймспейсов проверялся только на подписках контроллера рабочих нагрузок, поэтому удаление отчёта — вручную или по истечении срока хранения — заново запускало сканирование его рабочей нагрузки в любом неймспейсе. Отчёт VulnerabilityReport, оставшийся в таком неймспейсе, удаляется по истечении срока хранения, в пределах одного периода scanPeriods.workloadRescanPeriod, и больше не создаётся заново. У отчётов ExposedSecretReport и SbomReport собственного срока хранения нет, они сохраняются до удаления рабочей нагрузки.
• Команда trivy version в образе модуля выводила dev вместо номера версии, поэтому по самому сканеру нельзя было определить, какой релиз Trivy поставляет модуль. Теперь бинарный файл собирается с номером релизной версии.
• report-updater загружает словарь БДУ, если в секрете реестра учётные данные заданы парой username/password, указаны под ключом со схемой или путём репозитория либо выданы в виде токена. Такие учётные данные не распознавались: компонент обращался к реестру анонимно, получал 401 Unauthorized и циклически перезапускался, а модуль не переходил в состояние готовности. По той же причине обрезался пароль, содержащий двоеточие.
• report-updater берёт учётные данные реестра, в котором размещён образ БДУ, из секрета system-registry. Использовался секрет deckhouse-registry с учётными данными реестра источника модуля, поэтому словарь не загружался, если модуль и платформа поставляются из разных реестров или под разными учётными записями.
• registry-scanner находит учётные данные ресурса RegistryScanTarget, если ключ в секрете из registrySecretRef содержит схему или путь репозитория, а также если учётные данные Docker Hub хранятся под устаревшим ключом. Ключ должен был точно совпадать с полем registry, иначе цель сканировалась без учётных данных. Запись, в которой задан только токен, больше не перезаписывается: в конфигурацию, передаваемую сканированию, добавлялось поле auth, собранное из пустых имени пользователя и пароля, которое сканер считает некорректным.
• registry-scanner сохраняет отчёт по образу, в котором не найдено уязвимостей. Список уязвимостей — обязательное поле ресурса RegistryImageVulnerabilityReport, а пустой список передавался как null, поэтому отчёт отклонялся, а тег пересканировался на каждом цикле без сохранения отчёта.
• registry-scanner сканирует все репозитории реестра, если параметр spec.repositories ресурса RegistryScanTarget пуст. В справочнике пустой список всегда описывался именно так, но репозитории не запрашивались: такая цель завершала цикл за доли секунды и сообщала об успехе, ничего не просканировав. Теперь список берётся из catalog API реестра, а реестр, который каталог не отдаёт или отдаёт пустым, переводит цель в состояние Ready=False вместо сообщения об успешном цикле.
• registry-scanner сообщает о репозиториях, которые не удалось прочитать. Несуществующий репозиторий, отвергнутый сертификат и не принятые реестром учётные данные попадали только в лог, а цель сообщала Ready=True, не сохранив ни одного отчёта. Теперь такой цикл переводит цель в Ready=False, перечисляет репозитории с ошибкой по каждому и указывает число непросканированных образов.
• registry-scanner запрашивает список тегов с учётными данными самого модуля, если в ресурсе RegistryScanTarget секрет не указан. Сканирование их уже использовало, поэтому доступный модулю реестр сканировался, но список тегов запрашивался анонимно: приватные репозитории отвечали 401 Unauthorized, а публичные сканировались.
• registry-scanner больше не повторяет цикл согласования для цели с ошибкой без остановки. Цель с неуспешным циклом проходила согласование около десяти раз в секунду всё время, пока ошибка сохранялась, и на каждом проходе дважды писала в API-сервер, потому что контроллер реагировал на собственные записи статуса. Цикл, упавший до начала сканирования, теперь повторяется через пять минут, а просканировавший часть образов — через час.
• registry-scanner запускает цикл сканирования сразу после изменения спецификации ресурса RegistryScanTarget. Добавленный репозиторий или исправленный путь ждали истечения периода пересканирования, до семи суток, если вручную не удалить аннотацию времени последнего сканирования.
• registry-scanner отвечает на пробы, пока загружается индексная база Java. Загрузка выполнялась до запуска сервера проб, поэтому при медленном реестре kubelet убивал контейнер по liveness-пробе и загрузка начиналась заново, а компонент оставался в состоянии CrashLoopBackOff. Неудачная загрузка теперь повторяется каждые 30 секунд, а до её завершения компонент сообщает о неготовности и откладывает сканирование.
• SBOM кластера (k8s-cluster) снова получает отчёт ClusterVulnerabilityReport. Оператор передавал заданию сканирования пустой SBOM из проекции security-storage, содержащей только метаданные, а скан, запущенный после обновления модуля, пока trivy-server ещё загружал базу, завершался ошибкой и не повторялся. Теперь оператор читает полный SBOM, а скан до 90 секунд ожидает готовности trivy-server.
• Отчёт k8s-cluster описывает текущую версию Kubernetes. SBOM прошлой версии кластера оставался после обновления и использовал с текущим общий секрет sbom-k8s-cluster, поэтому отчёт мог строиться по любому из них. Теперь SBOM другой версии удаляется вместе с его отчётом.
• Секрет, через который SBOM передаётся заданию сканирования, больше не блокирует скан. Секрет, оставшийся без владельца, например после перезапуска оператора, принимался за идущий скан, и объект больше не сканировался. Теперь имя секрета содержит хеш сканируемого объекта, оставшийся секрет заменяется, а модуль удаляет секреты sbom-*, которые остаются без владельца дольше 10 минут.
• Упавшее задание сканирования, например после вытеснения его пода, повторяется до трёх раз для одной и той же спецификации пода. Раньше нагрузка оставалась без отчёта до изменения её спецификации.
• Отчёты о соответствии (ClusterComplianceReport) снова учитывают проваленные проверки. Оператор строил их по проекции отчётов аудита, содержащей только метаданные, без результатов проверок, поэтому все проверки считались пройденными.
• Проверка KSV-0110 (default_namespace_should_not_be_used) снова загружается. Оператор пропускал библиотеку Rego, от которой она зависит, и при старте писал в лог rego_type_error.
• Метрики trivy_image_vulnerabilities и trivy_image_exposedsecrets снова содержат лейблы образа, а у метрики trivy_vulnerability_id снова есть ряды. Оператор читал эти отчёты из проекции security-storage, содержащей только метаданные, без данных об образе и уязвимостях.
• registry-scanner сохраняет отчёт образа, размер которого превышает ограничение объекта в 1 МиБ. Отчёт урезается поэтапно: ссылки, описания, векторы CVSS, затем уязвимости низших уровней критичности. Счётчики summary остаются полными, а аннотация registry-scanner.deckhouse.io/trimmed перечисляет удалённые данные.
• Значение vulnerabilityDatabaseMaxAge: 0s отклоняется схемой конфигурации. Раньше оно принималось, и хук алерта о свежести trivy-db завершался ошибкой при каждом запуске.
• Проверки аудита конфигурации больше не перестают случайным образом компилироваться после старта оператора. Параллельные reconcile повреждали кешированный набор проверок, а сканер сохранял неудачный результат компиляции, поэтому до перезапуска оператора все отчёты ConfigAuditReport создавались без проверок, а все отчёты ClusterComplianceReport — без проваленных проверок. Набор проверок больше не изменяется совместно, а неудачная компиляция повторяется.

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

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

• Устранены CVE в образах модуля и зависимостях.

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

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

• Ресурс RegistryScanTarget с пустым параметром spec.repositories начнёт сканировать. До этого выпуска такая цель не сканировала ничего, а теперь берёт из каталога реестра до spec.maxRepositories репозиториев (по умолчанию 100), и их образы добавляются к нагрузке на сервер Trivy. Если нагрузка критична, задайте spec.maxRepositories таким целям до обновления или перечислите репозитории явно.
• Все ресурсы RegistryImageVulnerabilityReport пересоздаются под новыми именами в первом цикле после обновления. Имя отчёта теперь содержит хеш репозитория и тега, поэтому два образа, пути которых различались только символом, терявшимся при формировании имени, больше не делят один отчёт. Отчёты с прежними именами удаляет первый цикл, прочитавший все репозитории своей цели и просканировавший все её образы. Отчёты по образам, которые цикл не сканирует, — репозиторий вышел из цели, недоступен или не попал в лимит spec.maxRepositories — удаляет первый цикл, прочитавший все репозитории своей цели и просканировавший все её образы; до этого момента об этом сообщает условие Ready этой цели.
• Ресурс RegistryScanTarget, у которого прочитаны не все репозитории, переходит в состояние Ready=False с причиной ScanFailed. Раньше такая цель сообщала Ready=True, поэтому проверка, ожидающая готовности всех целей, может начать срабатывать на цели, которая и прежде сканировала лишь часть своих репозиториев.

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

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

• Исправлен пример tagFilter в справочнике RegistryScanTarget. Он был записан строкой YAML в двойных кавычках, где escape-последовательности регулярного выражения с обратным слешем недопустимы, поэтому скопированный в манифест пример вызывал ошибку разбора.
• В справочнике ModuleConfig у параметра severities указано значение по умолчанию: если параметр не задан, в отчёты об уязвимостях попадают все уровни критичности.
• В описании области сканирования разделены сканирование образов, ограниченное помеченными неймспейсами, и сканирование конфигураций, охватывающее все неймспейсы. Также указано, какие неймспейсы по умолчанию исключает параметр complianceReports.skipSystemResources, сколько живут отчёты неймспейса после снятия лейбла и почему в обоих случаях в логе оператора отображается режим установки AllNamespaces.

v0.6.7

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

Снижено потребление оперативной памяти security-storage в штатной работе за счёт внутренних оптимизаций хранилища.

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

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

• security-storage потребляет меньше памяти под нагрузкой благодаря оптимизациям хранения и кэширования.

Улучшения

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

• Уменьшен объём оперативной памяти, потребляемой security-storage при работе.

v0.6.6

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

Watch-запросы к security-storage поддерживают sendInitialEvents=true для корректной начальной синхронизации.

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

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

• Watch-запросы к security-storage принимают sendInitialEvents=true, поэтому клиенты получают начальный набор объектов до последующих событий.

Исправления

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

• Реализована недостающая поддержка параметра sendInitialEvents=true для watch-запросов к security-storage.

v0.6.5

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

Согласование кодировок YAML/JSON для ресурсов trivy.deckhouse.io и отдельная настройка StorageClass для PVC security-storage.

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

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

• Для ресурсов trivy.deckhouse.io согласовываются только кодировки YAML и JSON.
• StorageClass для PVC security-storage можно задать отдельно от остального модуля.

v0.6.4

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

Обновлены точки монтирования подов сканирования файловой системы узлов для совместимости с редакцией CSE Deckhouse Kubernetes Platform (DKP).

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

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

• Точки монтирования подов сканирования файловой системы узлов приведены к требованиям CSE.

v0.6.3

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

Включено сканирование корневой файловой системы узлов в редакции CSE, а для node-agent адаптированы securityContext и список точек монтирования.

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

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

• Сканирование корневой файловой системы узлов доступно в кластерах CSE.
• securityContext и точки монтирования node-agent приведены к требованиям CSE, чтобы агент корректно запускался и работал.

v0.6.2

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

Добавлены описания точек монтирования контейнеров сканирования для совместимости с редакцией CSE Deckhouse Kubernetes Platform (DKP).

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

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

• Объявлены точки монтирования контейнеров сканирования, чтобы сканирование узлов и нагрузок корректно работало в кластерах CSE.

v0.6.1

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

Добавлены описания точек монтирования компонента security-storage и контейнеров сканирования для совместимости с редакцией CSE Deckhouse Kubernetes Platform (DKP).

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

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

• Объявлены точки монтирования для security-storage и контейнеров сканирования, чтобы модуль корректно работал в кластерах CSE.