Модуль operator-trivy: FAQ

Просмотр ресурсов, не прошедших проверки соответствия CIS

Следующая команда выводит проверки CIS из ClusterComplianceReport cis, в которых есть хотя бы одна неуспешная проверка:

d8 k get clustercompliancereports.trivy.deckhouse.io cis -ojson |
  jq '.status.detailReport.results | map(select(.checks | map(.success) | all | not))'

Просмотр ресурсов, не прошедших конкретную проверку соответствия CIS

Чтобы просмотреть результаты одной проверки CIS, отфильтруйте ClusterComplianceReport cis по идентификатору проверки или по её описанию.

Фильтрация по идентификатору проверки:

check_id="5.6.4"
d8 k get clustercompliancereports.trivy.deckhouse.io cis -ojson |
  jq --arg check_id "$check_id" '.status.detailReport.results | map(select(.id == $check_id))'

Фильтрация по описанию проверки:

check_desc="The default namespace should not be used"
d8 k get clustercompliancereports.trivy.deckhouse.io cis -ojson |
  jq --arg check_desc "$check_desc" '.status.detailReport.results | map(select(.description == $check_desc))'

Ручной перезапуск сканирования ресурса

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

1. В неймспейсе с каждым просканированным ресурсом создаётся объект VulnerabilityReport.
2. В этом объекте присутствует аннотация trivy-operator.aquasecurity.github.io/report-ttl, которая указывает время жизни отчёта (по умолчанию совпадает с scanPeriods.workloadRescanPeriod).
3. По истечении этого времени объект удаляется, что вызывает повторное сканирование ресурса.

Установите scanPeriods.workloadRescanPeriod в "", чтобы отключить периодическое повторное сканирование (отчёты создаются однократно и не обновляются автоматически).

Принудительно запустить повторное сканирование ресурса можно одним из двух способов:

• Перезапишите аннотацию trivy-operator.aquasecurity.github.io/report-ttl, указав короткое время жизни отчёта.
• Удалите объект VulnerabilityReport из неймспейса, где находится просканированный ресурс.

Пример команды для перезаписи аннотации trivy-operator.aquasecurity.github.io/report-ttl:

d8 k -n <NAMESPACE> annotate vulnerabilityreports.trivy.deckhouse.io <REPORT_NAME> trivy-operator.aquasecurity.github.io/report-ttl=1h --overwrite

Где:

• <NAMESPACE> — неймспейс просканированного ресурса;
• <REPORT_NAME> — имя VulnerabilityReport. Чтобы получить список отчётов в неймспейсе, выполните d8 k -n <NAMESPACE> get vulnerabilityreports.trivy.deckhouse.io.

Ручной перезапуск сканирования репозитория реестра контейнеров

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

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

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

Доступ к результатам сканирования зависит от того, какая ролевая модель модуля user-authz используется в кластере.

В гранулярной ролевой модели доступ к результатам сканирования дают следующие роли:

• d8:use:role:viewer или выше, назначенная через RoleBinding в неймспейсе, — отчёты в этом неймспейсе (VulnerabilityReport, SbomReport, ConfigAuditReport, ExposedSecretReport, InfraAssessmentReport, RbacAssessmentReport) и SecurityScore;
• d8:manage:security:viewer или выше, назначенная через ClusterRoleBinding, — cluster-wide-отчёты (ClusterComplianceReport и другие отчёты Cluster*) и ClusterSecurityScore;
• d8:manage:permission:module:operator-trivy:view, назначенная через ClusterRoleBinding, — те же cluster-wide-отчёты без доступа к другим модулям подсистемы security.

Роли d8:manage:* дают доступ только к cluster-wide-отчётам. Доступа к NodeVulnerabilityReport и RegistryImageVulnerabilityReport они не дают: выдайте его через Kubernetes RBAC, как показано в примере ниже.

В упрощённой ролевой модели (AuthorizationRule и ClusterAuthorizationRule) доступ к результатам сканирования дают следующие уровни доступа:

• User или выше в AuthorizationRule или ClusterAuthorizationRule — namespaced-отчёты;
• ClusterEditor или выше в ClusterAuthorizationRule — cluster-wide-отчёты и NodeVulnerabilityReport.

Также доступ можно выдать напрямую через стандартный Kubernetes RBAC (Role или ClusterRole с RoleBinding или ClusterRoleBinding):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: trivy-reports-view
  namespace: <NAMESPACE>
rules:
- apiGroups: ["trivy.deckhouse.io", "aquasecurity.github.io"]
  resources:
  - vulnerabilityreports
  - configauditreports
  - exposedsecretreports
  - sbomreports
  - infraassessmentreports
  - rbacassessmentreports
  verbs: ["get", "list", "watch"]
- apiGroups: ["deckhouse.io"]
  resources:
  - securityscores
  verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: trivy-cluster-reports-view
rules:
- apiGroups: ["trivy.deckhouse.io", "aquasecurity.github.io"]
  resources:
  - clustercompliancereports
  - clustervulnerabilityreports
  - clusterconfigauditreports
  - clusterinfraassessmentreports
  - clusterrbacassessmentreports
  - clustersbomreports
  - nodevulnerabilityreports
  verbs: ["get", "list", "watch"]
- apiGroups: ["deckhouse.io"]
  resources:
  - clustersecurityscores
  - registryimagevulnerabilityreports
  verbs: ["get", "list", "watch"]

Какие рабочие нагрузки сканируются в неймспейсе

В неймспейсе с лейблом security-scanning.deckhouse.io/enabled="" оператор сканирует образы всех рабочих нагрузок следующих видов: Pod, ReplicaSet, ReplicationController, StatefulSet, DaemonSet, CronJob и Job. Ограничить список сканируемых рабочих нагрузок в неймспейсе нельзя.

Сказанное относится к сканированию образов. Сканирование конфигураций от лейбла не зависит и охватывает все неймспейсы, кроме исключённых параметром complianceReports.skipSystemResources и помеченных лейблом security.deckhouse.io/skip-compliance=true.

Как просмотреть отчёт по своему приложению

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

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

Как проверки CIS модуля соотносятся с kube-bench?

Модуль operator-trivy в Deckhouse Platform (DP) и kube-bench проверяют кластер на соответствие одному и тому же CIS Kubernetes Benchmark, но выполняют проверки по-разному и выводят результаты в разных форматах.

Что такое kube-bench?

kube-bench — это отдельная утилита от Aqua Security, которая проверяет соответствие кластера Kubernetes требованиям CIS Benchmark. Она выполняет shell-команды на узлах для анализа конфигурации.

Чтобы самостоятельно запустить проверки kube-bench в кластере DP, воспользуйтесь инструкцией по запуску kube-bench в кластере в FAQ модуля deckhouse.

Как модуль реализует проверки CIS?

Модуль выполняет проверки CIS с помощью Trivy Operator, который:

• работает как Kubernetes-оператор внутри кластера;
• проверяет объекты во всех неймспейсах, кроме исключённых из сканирования конфигураций;
• сохраняет результаты в ClusterComplianceReport;
• экспортирует метрики в Prometheus.

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

В таблице показано, какие проверки покрывают каждый раздел CIS в kube-bench и в DP:

Как сопоставить результаты?

Для сопоставления результатов используйте CIS Control ID (например, 1.2.1 или 5.2.2). Когда kube-bench выполняет проверки по CIS 1.12 (--benchmark cis-1.12), идентификаторы в обоих инструментах совпадают.

Пример: если kube-bench показывает [FAIL] 1.2.16 Ensure that the --audit-log-path argument is set (Automated), найдите ту же проверку в DP:

d8 k get clustercompliancereports.trivy.deckhouse.io cis -ojson | jq '.status.detailReport.results | map(select(.id == "1.2.16"))'

Подробнее — в разделе «Проверки CIS Kubernetes Benchmark».

Почему некоторые CIS-проверки всегда показывают PASS для системных компонентов?

Часть проверок отключена для системных неймспейсов (kube-system и d8-*), поскольку системные компоненты требуют расширенных привилегий.

Полный список отключённых проверок приведён в разделе «Проверки CIS Kubernetes Benchmark».

Почему проверки 5.1.2 и 5.1.3 не отображаются в метриках?

Проверки 5.1.2 (Minimize access to secrets) и 5.1.3 (Minimize wildcard use in Roles and ClusterRoles) исключены из метрик из-за большого количества ложных срабатываний для системных компонентов.

Проверки выполняются, результаты доступны в ресурсе ClusterComplianceReport:

d8 k get clustercompliancereports.trivy.deckhouse.io cis -ojson | jq '.status.detailReport.results | map(select(.id == "5.1.2" or .id == "5.1.3"))'

Какая версия CIS Benchmark используется?

Модуль реализует проверки согласно спецификации CIS Kubernetes Benchmark v1.12.

Версии компонентов, которые использует модуль:

Как часто выполняются проверки CIS?

Проверки CIS Benchmark выполняются по расписанию scanPeriods.complianceRescanCron (по умолчанию 0 */6 * * *, каждые 6 часов) и при запуске оператора.

Как ограничить нагрузку от задач сканирования

Задачи сканирования, которые загружают и разбирают образы контейнеров, могут быть ресурсоёмкими. Используйте следующие параметры модуля:

• concurrentScanJobsLimit — максимальное число одновременно выполняемых задач сканирования (по умолчанию 10);
• scanJobResources — запросы и лимиты CPU и памяти для подов задач сканирования. Если параметр не задан, используются запросы 100m/100M и лимиты 500m/500M;
• nodeSelector и tolerations — на каких узлах запускаются оператор и задачи сканирования.

Где хранятся отчёты о сканировании?

Место хранения отчётов о сканировании задаётся параметром securityStorageForReports:

• true (по умолчанию) — отчёты обслуживает агрегированный API-сервер security-storage в группе API trivy.deckhouse.io, а хранятся они на PVC security-storage;
• false — отчёты хранятся в etcd как кастомные ресурсы группы API aquasecurity.github.io. Отчёт по узлу с большим количеством пакетов может превысить ограничение etcd на размер объекта в 3 МБ, поэтому не отключайте фильтр severities.

CRD группы aquasecurity.github.io устанавливаются в обоих режимах. В командах d8 k указывайте ресурс вместе с группой API текущего режима, например clustercompliancereports.aquasecurity.github.io, если securityStorageForReports равен false. Команды в этой документации используют группу по умолчанию.

При изменении значения параметра существующие отчёты не переносятся. Оператор повторно сканирует рабочие нагрузки и узлы и создаёт отчёты в новом хранилище заново, поэтому до завершения повторного сканирования отчёты неполные. Судьба отчётов предыдущего режима зависит от направления переключения:

• после переключения на false PVC security-storage удаляется вместе с хранящимися в нём отчётами, если security-storage не остаётся запущенным из-за параметра nodeAgent.enabled;
• после возврата на true отчёты в etcd остаются в кластере и больше не обновляются, кроме ресурсов ClusterComplianceReport, которые модуль удаляет.

Если в режиме false security-storage оставался запущенным из-за параметра nodeAgent.enabled, после возврата на true ресурсы ClusterComplianceReport группы trivy.deckhouse.io возвращаются со статусом прошлого периода. Оператор сразу перестраивает такой отчёт, если его статус построен до текущего интервала расписания scanPeriods.complianceRescanCron, иначе — при следующем запуске по этому расписанию.

Чтобы удалить отчёты, оставшиеся в etcd после возврата на true, выполните команду:

for r in $(d8 k api-resources --api-group=aquasecurity.github.io -o name); do d8 k delete "$r" --all -A; done

Команда удаляет все ресурсы группы aquasecurity.github.io во всех неймспейсах. Сами CRD остаются.

Как расширить диск (PVC) модуля

Модуль хранит данные на следующих PVC в неймспейсе d8-operator-trivy:

• security-storage — данные рантайм-профилей (ApplicationProfile, NetworkNeighborhood) и, если параметр securityStorageForReports не равен false, отчёты о сканированиях (VulnerabilityReport, SbomReport, ClusterComplianceReport). Размер задаётся параметром securityStoragePVCRequest (по умолчанию 10 ГиБ);
• data-trivy-server-0 — кеш базы уязвимостей Trivy, 5Gi;
• data-trivy-provider-0 — кеш trivy-provider, 2Gi. Создаётся, только если denyVulnerableImages.enabled имеет значение true и включён модуль admission-policy-engine;
• data-registry-scanner-0 — кеш registry-scanner, 2Gi. Создаётся, только если registryScanning.enabled имеет значение true.

Размеры PVC data-* задаются в шаблонах модуля и через конфигурацию не настраиваются. Если параметр apiServerStorageClass (для security-storage) или storageClass (для PVC data-*) имеет значение false, вместо соответствующих PVC модуль использует emptyDir.

Расширить PVC можно, только если его StorageClass поддерживает расширение тома. Уменьшить размер PVC нельзя. Чтобы расширить PVC, выполните следующие шаги:

1. Убедитесь, что StorageClass допускает расширение (allowVolumeExpansion: true):

   d8 k get storageclass <STORAGE_CLASS> -o jsonpath='{.allowVolumeExpansion}'

   <STORAGE_CLASS> — имя StorageClass, который использует PVC (колонка STORAGECLASS в выводе команды d8 k -n d8-operator-trivy get pvc).

2. Увеличьте размер PVC:

   • Для security-storage увеличьте значение параметра securityStoragePVCRequest. Модуль формирует этот PVC из значения параметра, поэтому не изменяйте его вручную. Если PVC уже запрашивает больше значения параметра, модуль сохраняет его размер. Если StorageClass не поддерживает расширение томов, модуль сохраняет и размер меньшего PVC.

   • Для PVC data-* увеличьте запрос на хранилище у существующего PVC:

     d8 k -n d8-operator-trivy patch pvc <PVC_NAME> --type merge -p '{"spec":{"resources":{"requests":{"storage":"<NEW_SIZE>"}}}}'

     Где:

     • <PVC_NAME> — data-trivy-server-0, data-trivy-provider-0 или data-registry-scanner-0;
     • <NEW_SIZE> — новый размер, больше текущего, например 10Gi.

     Поле volumeClaimTemplates у StatefulSet неизменяемо, поэтому в шаблоне остаётся исходный размер. StatefulSet продолжает использовать существующий расширенный PVC. Если PVC будет создан заново, например после смены StorageClass, он снова получит размер из шаблона.

3. В зависимости от CSI-драйвера том расширится онлайн либо после перезапуска пода, который его использует.