Модуль operator-trivy: FAQ

Просмотр ресурсов, которые не прошли CIS compliance-проверки

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

Просмотр ресурсов, которые не прошли конкретную CIS compliance-проверку

По id:

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

По описанию:

check_desc="Apply Security Context to Your Pods and Containers"
d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson |
  jq --arg check_desc "$check_desc" '.status.detailReport.results | map(select(.description == $check_desc))'

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

Модуль выполняет повторное сканирование ресурсов каждые 24 часа согласно следующему алгоритму:

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

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

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

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

d8 k annotate VulnerabilityReport -n <namespace> <reportName> trivy-operator.aquasecurity.github.io/report-ttl=1h --overwrite

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

Доступ к результатам сканирования (в том числе возможность просматривать ресурсы с результатами) предоставляется пользователям, обладающим следующими ролями доступа:

• d8:manage:networking:viewer или выше;
• d8:manage:permission:module:operator-trivy:view.

Примечание: это роли экспериментальной ролевой модели DKP.

• Чтобы дать доступ к отчётам в конкретном неймспейсе (VulnerabilityReport, ConfigAuditReport и т. п.), используйте RoleBinding с use-ролью d8:use:role:viewer (или выше) в этом неймспейсе.
• Чтобы дать доступ к cluster-wide отчётам (ClusterComplianceReport и т. п.), используйте ClusterRoleBinding с ролью d8:manage:permission:module:operator-trivy:view (либо более широкой d8:manage:security:viewer или выше).

Также в текущей ролевой модели DKP (ресурсы AuthorizationRule / ClusterAuthorizationRule) можно ориентироваться на следующие уровни доступа:

• Уровень неймспейса (AuthorizationRule в конкретном неймспейсе): User, PrivilegedUser, Editor, Admin.
• Уровень кластера (ClusterAuthorizationRule для cluster-wide отчётов и/или доступа к системным неймспейсам): ClusterEditor, ClusterAdmin, SuperAdmin.

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

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

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

Как ограничить список сканируемых ресурсов в пространстве имён

В текущей версии функциональности ограничения перечня ресурсов для сканирования в пространстве имён не предусмотрено.
Оператор сканирует все ресурсы, находящиеся в пространстве имён, помеченном меткой security-scanning.deckhouse.io/enabled="".

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

Для просмотра результатов сканирования вашего приложения воспользуйтесь Grafana-дашбордом Security / Trivy Image Vulnerability Overview.
Вы можете отфильтровать результаты по нужному пространству имён и ресурсу.

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

Как проверки CIS в DKP соотносятся с kube-bench?

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

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

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

Как DKP реализует CIS-проверки?

DKP использует Trivy Operator — интегрированное решение, которое:

• Работает как Kubernetes-оператор внутри кластера
• Автоматически сканирует все ресурсы
• Сохраняет результаты в Custom Resources (ClusterComplianceReport)
• Экспортирует метрики в Prometheus

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

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

Используйте CIS Control ID (например, 1.2.1, 5.2.2) — он одинаковый в обоих инструментах.

Пример: Если kube-bench показывает [FAIL] 1.2.16 Ensure that the admission control plugin..., найдите в DKP:

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

Подробнее см. в документации по CIS-проверкам.

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

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

Полный список отключённых проверок см. в документации по CIS-проверкам.

Почему проверки 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.aquasecurity.github.io cis -ojson | \
  jq '.status.detailReport.results | map(select(.id == "5.1.2" or .id == "5.1.3"))'

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

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

Версии компонентов (внешний модуль operator-trivy, DKP 1.75+):

Примечание: В DKP 1.74 и ранее использовался встроенный модуль с Trivy v0.55.2.

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

Проверки CIS Benchmark выполняются:

• каждые 6 часов (cron: 0 */6 * * *);
• при запуске оператора.