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

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

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.