Модуль operator-trivy

Модуль регулярно проверяет образы запущенных рабочих нагрузок на известные CVE, включая уязвимости из баз Astra Linux, РЕД ОС и ALT Linux. Базируется на проекте Trivy. Для сканирования используются публичные базы уязвимостей, обогащаемые базами Astra Linux, ALT Linux и РЕД ОС.

Также модуль производит анализ соответствия кластера Kubernetes требованиям CIS Kubernetes Benchmark и другим стандартам. Полный список приведён в разделе «Отчёты соответствия».

Основные возможности

• Автоматическое CVE-сканирование образов контейнеров в помеченных неймспейсах. По умолчанию отчёты пересоздаются каждые 24 часа; интервал задаётся параметром scanPeriods.workloadRescanPeriod.
• Анализ соответствия кластера требованиям CIS Kubernetes Benchmark с сохранением результатов в ClusterComplianceReport.
• Генерация SBOM для всех сканируемых образов контейнеров (SbomReport).
• Опциональное сканирование файловой системы узлов для обнаружения уязвимостей ОС (NodeVulnerabilityReport).
• Опциональное периодическое сканирование образов во внешних реестрах контейнеров (RegistryScanTarget).
• Обнаружение утечек секретов в образах контейнеров (ExposedSecretReport).
• Опциональная блокировка уязвимых образов на этапе admission (denyVulnerableImages).
• События безопасности о найденных уязвимостях, секретах и нарушениях конфигурации для модуля security-events-manager.
• Опциональная карта приложений и сети по рантайм-поведению (nodeAgent, предварительная версия).
• Метрики Prometheus и Deckhouse Console для результатов сканирования уязвимостей; результаты CIS и других проверок соответствия — в ClusterComplianceReport.

Механизм сканирования, отчёты VulnerabilityReport и SbomReport, блокировка уязвимых образов и базы данных CVE описаны в разделе «Сканирование на уязвимости». Полный список настроек модуля — в разделе «Настройки».

Системные требования и рекомендации

Для работы модуля требуется:

• Deckhouse Platform (DP) версии 1.76 или новее;
• StorageClass для данных модуля на базе блочных сетевых или локальных устройств или локальных путей (localpath). Модуль хранит результаты сканирования и поведенческие модели рабочих нагрузок в собственной базе данных (security-storage), а не в etcd кластера. Чтобы хранить результаты сканирования в etcd, задайте параметру securityStorageForReports значение false. Не используйте StorageClass на базе сетевых файловых или объектных хранилищ, например NFS, CephFS или S3. Параметр apiServerStorageClass задаёт StorageClass для security-storage. Кеши сервера Trivy и других компонентов сканирования используют параметр storageClass;
• для блокировки уязвимых образов (denyVulnerableImages) — модуль admission-policy-engine.

Доступность в редакциях

Модуль доступен в редакциях DP Enterprise Edition (EE) и Certified Security Edition (CSE). В CSE модуль включён по умолчанию в наборах модулей Default и Managed.

Область сканирования

Сканеры модуля разделены на две группы с разной областью действия.

Сканирование образов включается явно. Оно выполняется только в неймспейсах с лейблом security-scanning.deckhouse.io/enabled="" и формирует отчёты VulnerabilityReport, SbomReport и ExposedSecretReport. Если в кластере отсутствуют неймспейсы с указанным лейблом, сканируется неймспейс default. Как только в кластере появляется неймспейс с этим лейблом, сканирование неймспейса default прекращается.

Чтобы снова включить сканирование для неймспейса default, установите у него лейбл:

d8 k label namespace default security-scanning.deckhouse.io/enabled=""

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

Сканирование конфигураций лейбла не требует и охватывает все неймспейсы, чтобы отчёт ClusterComplianceReport строился по всему кластеру. Оно формирует отчёты ConfigAuditReport, RbacAssessmentReport и InfraAssessmentReport. Параметр complianceReports.skipSystemResources по умолчанию имеет значение true, и тогда отчёты ConfigAuditReport и RbacAssessmentReport в неймспейсах d8-*, kube-* и default не создаются вовсе. Лейбл security.deckhouse.io/skip-compliance=true у объекта Namespace исключает неймспейс так же, независимо от значения параметра. На отчёт InfraAssessmentReport эти исключения не распространяются, поэтому проверки CIS Kubernetes Benchmark для компонентов управляющего слоя продолжают работать.

Из-за этого разделения в логе оператора режим установки отображается как AllNamespaces с пустым списком целевых неймспейсов, даже если лейбл установлен ровно на одном неймспейсе. Эта строка описывает область сканирования конфигураций, а не образов.

После снятия лейбла новые сканирования образов в неймспейсе не запускаются, но уже созданные отчёты удаляются не сразу. Отчёт VulnerabilityReport удаляется по истечении срока хранения, в пределах одного периода scanPeriods.workloadRescanPeriod (по умолчанию 24h), и заново не создаётся. У отчётов ExposedSecretReport и SbomReport собственного срока хранения нет, они сохраняются до удаления рабочей нагрузки.

Условия запуска сканирования

Сканирование запускается автоматически, когда возраст отчёта превышает scanPeriods.workloadRescanPeriod (по умолчанию 24h), и при развёртывании компонентов, использующих новые образы, в неймспейсах, для которых включено сканирование.

Где просматривать результаты сканирования

В Deckhouse Console сводный обзор уязвимостей в образах и ресурсах кластера находится в разделе «Система» → «Управление системой» → «Безопасность» → «Уязвимости» → «По рабочим нагрузкам».

Результаты сканирования также хранятся в объектах кластера:

• отчёты о безопасности кластера:

  • ClusterComplianceReport — соответствие CIS Kubernetes Benchmark и другим стандартам;
  • ClusterRbacAssessmentReport — ошибки конфигурации RBAC в ClusterRole;
  • NodeVulnerabilityReport — уязвимости в пакетах операционной системы узлов;
  • RegistryImageVulnerabilityReport — уязвимости в образах из внешних реестров контейнеров;

• отчёты о безопасности ресурсов кластера:

  • VulnerabilityReport — уязвимости в образах контейнеров;
  • SbomReport — состав ПО в образах (SBOM);
  • ConfigAuditReport — ошибки конфигурации Kubernetes-объектов;
  • RbacAssessmentReport — ошибки конфигурации RBAC в Role;
  • ExposedSecretReport — утечки секретов в контейнерах.

Сводная оценка безопасности публикуется в ресурсах ClusterSecurityScore для кластера и SecurityScore в каждом пользовательском неймспейсе. Как она считается, описано в разделе «Оценка безопасности».