Сканирование на уязвимости

В кластере DKP сканирование на уязвимости выполняется с помощью оператора Trivy Operator. Он автоматически генерирует Software Bill Of Materials (SBOM) для всех рабочих нагрузок и запускает сканирование для заданных объектов без ручного вмешательства.

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

Сканирование поддерживается для следующих типов объектов:

• образы контейнеров, размещённые в хранилище (registry);
• файловые системы узлов кластера.

Архитектура анализа

Независимо от типа объекта сканирование выполняется в три этапа:

Механизм сканирования уязвимостей

Сканер уязвимостей является центральным компонентом Trivy: он выявляет известные уязвимости на основе специализированных баз данных. Модуль operator-trivy сканирует пакеты и компоненты операционной системы (исполняемые файлы, библиотеки) и зависимости приложений (библиотеки, модули и прочие зависимости).

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

Пакеты операционной системы

Сканер автоматически определяет дистрибутив ОС и применяет соответствующие данные из баз уязвимостей, предоставляемых DKP.

Используются следующие источники данных:

• Банк данных угроз безопасности информации ФСТЭК России (БДУ ФСТЭК);
• AlmaLinux Errata;
• Alpine SecDB;
• ALTRepo Errata OVAL;
• Amazon Linux Security Advisories;
• Arch Linux Security Tracker;
• Debian Security Tracker;
• GitHub Security Advisory Database;
• National Vulnerability Database (NVD);
• Oracle OVAL;
• Photon Security Advisory;
• Red Hat OVAL;
• RED SOFT OVAL;
• Rocky Linux UpdateInfo;
• SUSE Security CVRF;
• Ubuntu CVE Tracker;
• Wolfi SecDB.

Зависимости приложений

Сканер обнаруживает и анализирует файлы манифестов пакетных менеджеров и lock-файлы более чем двадцати экосистем. Для каждого языка используются специализированные базы уязвимостей, преимущественно основанные на GitLab Advisory Database и GitHub Advisory Database.

Результаты сканирования и ресурс VulnerabilityReport

Результаты сканирования уязвимостей сохраняются в кластере в виде кастомного ресурса VulnerabilityReport группы aquasecurity.github.io. Каждый отчёт создаётся в неймспейсе рабочей нагрузки, именуется по схеме <kind>-<workload-name>-<container-name> и содержит перечень обнаруженных уязвимостей с указанием серьёзности, статуса исправления, затронутого пакета и ссылок на источники.

Отчёт привязывается к родительскому ресурсу через поле ownerReferences. При обновлении образа или удалении рабочей нагрузки устаревший VulnerabilityReport удаляется механизмом сборки мусора Kubernetes и при необходимости пересоздаётся.

Генерация и обработка SBOM

Сгенерированный SBOM сохраняется в кластере в виде CRD SbomReport группы aquasecurity.github.io. Каждый отчёт создаётся в неймспейсе рабочей нагрузки и содержит:

• метаданные контейнерного образа (репозиторий, тег, дайджест);
• компонентный состав в формате CycloneDX (пакеты ОС и зависимости приложений с идентификаторами PURL, лицензиями и информацией о поставщике);
• граф зависимостей между компонентами;
• сводку по количеству компонентов и зависимостей.

Оператор отслеживает изменения ресурсов кластера. При создании или изменении рабочей нагрузки автоматически запускается задание сканирования, по результатам которого одновременно формируются SbomReport и VulnerabilityReport. Оба отчёта именуются по схеме <kind>-<workload-name>-<container-name> и привязываются к родительскому ресурсу через поле ownerReferences. При удалении рабочей нагрузки отчёты удаляются автоматически через механизм сборки мусора Kubernetes.

SbomReport и VulnerabilityReport дополняют друг друга: VulnerabilityReport содержит выявленные уязвимости, а SbomReport фиксирует полный состав компонентов образа.

Сканирование реестров

Помимо сканирования образов, запущенных в кластере, модуль поддерживает периодическое сканирование репозиториев образов, хранящихся во внешних реестрах контейнеров.

Включите функцию в ModuleConfig/operator-trivy:

spec:
  settings:
    registryScanning:
      enabled: true

Настройка сканирования репозиториев в реестрах

Целевой реестр контейнеров для сканирования описывается cluster-scoped ресурсом RegistryScanTarget:

apiVersion: deckhouse.io/v1alpha1
kind: RegistryScanTarget
metadata:
  name: preprod-myapp
spec:
  registry: preprod.registry.example.com
  repositories:
    - myapp/backend
    - myapp/frontend
  rescanPeriod: 1d
  tagFilter: "^v[0-9]+"    # Опционально: сканировать только теги, соответствующие регулярному выражению.
  maxTags: 50              # Опционально: не более 50 тегов на репозиторий (по умолчанию 100).
  registrySecretRef:       # Опционально: учётные данные для приватного реестра.
    name: image-pull-credentialssecret
    namespace: myapp

Если реестр требует CA-сертификат, отсутствующий в системном хранилище доверенных сертификатов, добавьте его с помощью параметра additionalRegistryCA.

Результаты сканирования

Результаты сохраняются в cluster-scoped ресурсах RegistryImageVulnerabilityReport, по одному на каждый сканируемый тег образа. Каждый отчёт принадлежит своему RegistryScanTarget. При удалении объекта RegistryScanTarget связанные с ним отчёты автоматически удаляются механизмом сборки мусора Kubernetes.

# Список всех отчётов.
d8 k get registryimagevulnerabilityreport

# Просмотр конкретного отчёта.
d8 k describe registryimagevulnerabilityreport <name>

Отчёт пересоздаётся по истечении периода, заданного параметром rescanPeriod. Чтобы запустить внеплановое сканирование, удалите аннотацию registry-scanner.deckhouse.io/last-scan-time у объекта RegistryScanTarget. Контроллер запустит новый цикл сканирования, не дожидаясь следующего запуска по расписанию.

Состояние сканирования

Статус объекта RegistryScanTarget показывает время последнего цикла и его результат:

d8 k get registryscantarget
d8 k describe registryscantarget my-registry

Условие Ready принимает значение True после успешного завершения цикла сканирования и False во время сканирования или при возникновении ошибки.

Чтобы отличить ошибку от выполняющегося сканирования, проверьте значение поля reason.

Запрет запуска уязвимых контейнеров

Модуль реализует принудительный контроль над запуском контейнеров с уязвимыми образами на уровне admission-контроля Kubernetes. Механизм основан на связке OPA Gatekeeper (модуль admission-policy-engine) и Trivy: Trivy предоставляет результаты сканирования, а Gatekeeper принимает решение о допуске ресурса.

Ограничение применяется к ресурсам Pod, Deployment, StatefulSet и DaemonSet в неймспейсах с лейблом security.deckhouse.io/trivy-provider: "".

Конфигурация

Управление блокировкой осуществляется через параметр denyVulnerableImages в настройках модуля:

Пример конфигурации

spec:
  settings:
    denyVulnerableImages:
      enabled: true
      allowedSeverityLevels:
        - UNKNOWN
        - LOW
        - MEDIUM
      registrySecrets:
        - name: my-private-registry-pull-secret
          namespace: my-app

В приведённом примере блокируются образы с уязвимостями уровня HIGH или CRITICAL. Образы с уязвимостями уровней UNKNOWN, LOW, MEDIUM допускаются к запуску. Секрет my-private-registry-pull-secret используется чтобы trivy-provider мог скачивать образы из этого реестра при admission-проверке.

Подавление уязвимостей с помощью VEX-аттестаций

VEX (Vulnerability Exploitability eXchange) — машиночитаемое утверждение о том, является ли известная CVE реально эксплуатируемой в конкретной версии продукта. Например, VEX-утверждение может указывать, что уязвимость присутствует в библиотеке, поставляемой с образом, однако недостижима, потому что затронутый участок кода никогда не вызывается.

При включённом параметре useVEXFromOCI Trivy получает VEX-аттестации, прикреплённые к сканируемым образам в OCI-реестре (как OCI referrers), и использует их для фильтрации найденных уязвимостей. Уязвимость исключается из VulnerabilityReport или RegistryImageVulnerabilityReport, если VEX-утверждение помечает её как not_affected или fixed для данного образа.

Это работает как при сканировании рабочих нагрузок (образов, запущенных в кластере), так и при сканировании реестров контейнеров (RegistryScanTarget).

Требования

• Реестр должен поддерживать OCI Referrers API (OCI Distribution Spec v1.1+). Большинство современных реестров (Harbor, Quay, GHCR, ECR) поддерживают его.
• VEX-аттестации должны храниться как OCI referrers образа.

Включение

Добавьте следующий параметр в ModuleConfig/operator-trivy:

spec:
  settings:
    useVEXFromOCI: true

Отчёты соответствия (compliance)

Модуль создаёт ресурсы ClusterComplianceReport для выбранных фреймворков соответствия. Каждый отчёт обновляется каждые 6 часов и сопоставляет контролы фреймворка с проверками конфигурации и нагрузок, выполняемыми Trivy.

Набор развёртываемых отчётов задаётся параметром complianceReports.enabled.

Пример конфигурации

complianceReports:
  enabled:
    - CIS
    - NSA
    - FSTEC-21
    - FZ-187

В приведённом примере развёртываются только четыре отчёта. Для просмотра отчёта используйте:

d8 k get clustercompliancereports
d8 k describe clustercompliancereport fstec-21

Что попадает в отчёты соответствия

По умолчанию отчёты соответствия сфокусированы на ваших нагрузках — на том, что владелец кластера может реально исправить. Модуль автоматически исключает из compliance:

• ресурсы, управляемые Deckhouse и его модулями;
• системные компоненты Kubernetes (встроенные RBAC, дефолтные cluster-scoped объекты и т. п.).

Сам control plane при этом продолжает проверяться по соответствующим инфраструктурным контролам (например, раздел 1.x CIS Kubernetes Benchmark для параметров kube-apiserver, etcd, kube-scheduler) — отсекаются только общие workload-проверки для платформенных подов.

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

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

d8 k label namespace my-namespace security.deckhouse.io/skip-compliance=true

Работа с приватными и небезопасными реестрами

По умолчанию модуль ожидает, что все реестры контейнеров используют доверенные TLS-сертификаты. Для окружений с самоподписанными сертификатами, HTTP-реестрами или отключённой проверкой TLS доступны следующие параметры.

Корневые сертификаты для приватных реестров (additionalRegistryCA)

Параметр additionalRegistryCA задаёт корневые CA-сертификаты для частных реестров контейнеров.

Каждая запись содержит поле name (произвольная метка, только для справки) и ca (сертификат или цепочка в формате PEM). При указании цепочки объедините сертификаты последовательно в формате PEM без лишних пустых строк между ними.

spec:
  settings:
    additionalRegistryCA:
      - name: корпоративный CA
        ca: |
          -----BEGIN CERTIFICATE-----
          ...
          -----END CERTIFICATE-----
      - name: CA с промежуточным сертификатом
        ca: |
          -----BEGIN CERTIFICATE-----
          ...
          -----END CERTIFICATE-----
          -----BEGIN CERTIFICATE-----
          ...
          -----END CERTIFICATE-----

Небезопасные реестры (insecureRegistries)

Параметр insecureRegistries разрешает сканеру подключаться к указанным реестрам по HTTP или по HTTPS без проверки сертификата. Каждая запись — имя хоста реестра (опционально с портом).

spec:
  settings:
    insecureRegistries:
      - my.internal-registry.example.com
      - legacy-registry.example.com:5000

Параметр применяется при сканировании рабочих нагрузок (scan jobs), при admission-проверке (denyVulnerableImages) и при сканировании сторонних реестров (RegistryScanTarget).

Управление базами данных

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

В изолированных окружениях поддерживается загрузка баз данных и их локальное использование без доступа к интернету с помощью CLI-утилиты d8 (через команду d8 mirror).