Модуль 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 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-драйвера том расширится онлайн либо после перезапуска пода, который его использует.