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

В кластере 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 фиксирует полный состав компонентов образа.

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

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

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

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

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

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

denyVulnerableImages:
  enabled: true
  allowedSeverityLevels:
    - UNKNOWN
    - LOW
    - MEDIUM

В приведённом примере блокируются образы, содержащие уязвимости уровня HIGH или CRITICAL. Образы с уязвимостями уровней UNKNOWN, LOW, MEDIUM допускаются к запуску.

Отчёты соответствия (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

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

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

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