Модуль operator-trivy: проверки CIS Kubernetes Benchmark

Модуль выполняет автоматические проверки безопасности кластера в соответствии со спецификацией CIS Kubernetes Benchmark.

Используемая версия

Модуль реализует проверки согласно спецификации CIS Kubernetes Benchmark v1.12 (канонический бенчмарк для Kubernetes 1.32–1.34, применяется также к 1.35). Прошлые версии DKP поставляли спецификацию v1.23, которая фактически соответствует CIS Kubernetes Benchmark v1.5.0 (эра Kubernetes 1.22).

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

d8 k -n d8-operator-trivy get pods -o json | \
  jq -r '.items[] | .metadata.name as $p | .spec.containers[] | "\($p)\t\(.name)\t\(.image)"'

Категории проверок

Проверки CIS Kubernetes Benchmark сгруппированы по следующим категориям:

Исключения

В Deckhouse Kubernetes Platform (DKP) часть проверок отключена или исключена из отчётов. Это обусловлено архитектурными особенностями платформы и требованиями к работе системных компонентов.

Глобально отключённые проверки

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

CIS 1.2.1 — Anonymous auth (AVD-KCV-0001)

Проверка: Ensure that the --anonymous-auth argument is set to false.

Статус: Полностью отключена.

Причина: Проверка Trivy/defsec для CIS 1.2.1 основана на анализе устаревшего флага --anonymous-auth. В современных версиях Kubernetes настройка анонимной аутентификации может задаваться иначе (например, через AuthenticationConfiguration), поэтому флаговая проверка может давать ложные FAIL/WARN (в том числе в kube-bench). Для аудита используйте фактическую конфигурацию kube-apiserver и ограничения доступа в вашей инфраструктуре.

CIS 1.2.13 — SecurityContextDeny (AVD-KCV-0013)

Проверка: Ensure that the admission control plugin SecurityContextDeny is set if PodSecurityPolicy is not used.

Статус: Полностью отключена.

Причина: Admission controller SecurityContextDeny был объявлен устаревшим и полностью удалён в Kubernetes v1.30. Этот контроллер блокировал поды с привилегированными настройками, но его подход был слишком грубым и не позволял гранулярно настраивать политики.

Альтернатива в DKP: Deckhouse использует Pod Security Standards, реализованные в модуле admission-policy-engine на базе OPA Gatekeeper. Это позволяет:

• Применять политики Privileged, Baseline или Restricted на уровне неймспейса
• Создавать исключения для конкретных workloads
• Гибко настраивать правила под требования организации

Проверки, отключённые для системных неймспейсов

Следующие проверки отключены для неймспейсов kube-system и d8-* (все неймспейсы Deckhouse начинаются с префикса d8-).

Почему системным компонентам нужны привилегии?

Kubernetes-кластер требует компонентов, работающих на низком уровне: управление сетью, хранилищем, мониторинг ресурсов хоста. Эти компоненты по своей природе не могут работать в изолированном контейнере без привилегий.

Частичные исключения

Для отдельных ресурсов действуют специфические исключения:

CIS 5.7.4 — Default namespace (AVD-KSV-0110)

Проверка: The default namespace should not be used.

Исключение: Ресурс default/service-kubernetes.

Причина: Сервис kubernetes в неймспейсе default — это встроенный сервис Kubernetes API Server. Он создаётся автоматически при инициализации кластера и не может быть перемещён в другой неймспейс. Это стандартное поведение Kubernetes, задокументированное в официальной документации.

CIS 5.7.3 — Security Context (AVD-KSV-0020, AVD-KSV-0021)

Проверка: Apply Security Context to Your Pods and Containers.

Исключение: ReplicaSets в неймспейсах d8-*.

Причина: Проверки требуют runAsUser > 10000 и runAsGroup > 10000 (использование непривилегированных UID/GID). В DKP существуют системные workloads, которые запускаются от root (runAsUser/runAsGroup = 0) или не задают runAsUser/runAsGroup явно — это может быть нужно для совместимости с доступом к файловой системе хоста и низкоуровневыми операциями.

• Совместимости с правами доступа на файлы хоста
• Корректной работы с volumes, где права уже настроены
• Соответствия стандартным практикам системных сервисов

Как проверить, какие объекты “ниже порога” 5.7.3 в вашем кластере (читаемый формат):

Краткая сводка (pod-level runAsUser/runAsGroup) для системных неймспейсов d8-*, kube-system, kube-public, kube-node-lease:

d8 k get deploy,rs,ds,sts -A -o json | jq -r '
  .items[]
  | select(.metadata.namespace | test("^(d8-)|^(kube-system|kube-public|kube-node-lease)$"))
  | . as $o
  | ($o.spec.template.spec.securityContext.runAsUser // null) as $u
  | ($o.spec.template.spec.securityContext.runAsGroup // null) as $g
  | select((($u|tonumber? // -1) <= 10000) or (($g|tonumber? // -1) <= 10000))
  | [
      $o.kind,
      $o.metadata.namespace,
      $o.metadata.name,
      ("runAsUser=" + (($u|tostring) // "null")),
      ("runAsGroup=" + (($g|tostring) // "null"))
    ] | @tsv'

Детализация по контейнерам (container-level runAsUser/runAsGroup), чтобы увидеть, что задано на уровне pod и что — на уровне container:

d8 k get deploy,rs,ds,sts -A -o json | jq -r '
  .items[]
  | select(.metadata.namespace | test("^(d8-)|^(kube-system|kube-public|kube-node-lease)$"))
  | . as $o
  | ($o.spec.template.spec.securityContext.runAsUser // null) as $pu
  | ($o.spec.template.spec.securityContext.runAsGroup // null) as $pg
  | $o.spec.template.spec.containers[]?
  | . as $c
  | ($c.securityContext.runAsUser // null) as $cu
  | ($c.securityContext.runAsGroup // null) as $cg
  | select((($pu|tonumber? // 999999) <= 10000) or (($pg|tonumber? // 999999) <= 10000) or (($cu|tonumber? // 999999) <= 10000) or (($cg|tonumber? // 999999) <= 10000))
  | [
      $o.kind,
      $o.metadata.namespace,
      $o.metadata.name,
      ("pod.runAsUser=" + (($pu|tostring) // "null")),
      ("pod.runAsGroup=" + (($pg|tostring) // "null")),
      ("container=" + $c.name),
      ("container.runAsUser=" + (($cu|tostring) // "null")),
      ("container.runAsGroup=" + (($cg|tostring) // "null"))
    ] | @tsv'

Проверки, исключённые из метрик

Следующие проверки выполняются, но их результаты не отображаются в Prometheus-метриках и на дашборде Grafana. Это сделано намеренно, чтобы дашборд отражал реальные проблемы безопасности, а не ложные срабатывания.

CIS 5.1.2 — Access to secrets (AVD-KSV-0041)

Проверка: Minimize access to secrets.

Что проверяет: Находит все Roles/ClusterRoles с правами get, list или watch на ресурс secrets.

Почему исключена из метрик:

В оригинальном CIS Benchmark эта проверка помечена как type: manual и scored: false, потому что:

• Невозможно автоматически определить, легитимен ли доступ к secrets
• Любой контроллер, работающий с TLS или credentials, требует такого доступа

Примеры ролей с легитимным доступом к secrets в DKP:

• d8:ingress-nginx:kruise-role — управление секретами для ingress-контроллеров
• d8:node-manager:machine-controller-manager — роль для machine-controller-manager (ns d8-cloud-instance-manager) читает secrets/configmaps
• d8:operator-prometheus — ClusterRole оператора Prometheus читает/создаёт secrets
• Role/d8-log-shipper/log-shipper — Role модуля log-shipper читает secrets в d8-log-shipper

Где посмотреть полный список ролей/кто имеет доступ к secrets:

# Все Roles/ClusterRoles, которые имеют доступ к secrets (get/list/watch)
d8 k get clusterroles,roles -A -o json | jq -r '
  .items[]
  | select(any(.rules[]?;
      ((.resources // []) | index("secrets")) != null
      and (
        ((.verbs // []) | index("get")) != null
        or ((.verbs // []) | index("list")) != null
        or ((.verbs // []) | index("watch")) != null
      )
    ))
  | "\(.kind)\t\(.metadata.namespace // "-")\t\(.metadata.name)"'

# Быстрый поиск привязок по имени роли (пример)
role_name="d8:operator-prometheus"
d8 k get clusterrolebindings,rolebindings -A | grep -F "$role_name"

Как анализировать результаты:

# Получить все роли с доступом к secrets
d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson | \
  jq '.status.detailReport.results | map(select(.id == "5.1.2")) | .[].checks'

Проанализируйте список и убедитесь, что:

• Все роли принадлежат известным системным компонентам
• Нет пользовательских ролей с избыточным доступом

CIS 5.1.3 — Wildcard use in Roles (AVD-KSV-0044, AVD-KSV-0045, AVD-KSV-0046)

Проверка: Minimize wildcard use in Roles and ClusterRoles.

Что проверяет: Находит роли с wildcards (*) в полях resources, verbs или apiGroups.

Почему исключена из метрик:

В оригинальном CIS Benchmark эта проверка помечена как type: manual и scored: false, потому что:

• cluster-admin — стандартная роль Kubernetes, содержит wildcards
• Операторы часто требуют широкого доступа для управления разнообразными ресурсами

Примеры легитимного использования wildcards в DKP:

• cluster-admin — полный доступ для администраторов
• deckhouse ClusterRole — управление всеми модулями Deckhouse
• CRD-операторы — доступ ко всем ресурсам своего API group

Как анализировать результаты:

# Получить все роли с wildcards
d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson | \
  jq '.status.detailReport.results | map(select(.id == "5.1.3")) | .[].checks'

Убедитесь, что wildcards используются только в:

• Системных ролях Kubernetes (cluster-admin, admin, edit, view)
• Ролях компонентов Deckhouse (d8-*)
• Ролях известных операторов

Известные особенности

Проверка TLS-сертификатов kubelet (CIS 4.2.10)

Проверки AVD-KCV-0088 и AVD-KCV-0089 могут показывать статус FAIL. Это ожидаемое поведение: Deckhouse использует механизм автоматической ротации сертификатов kubelet (RotateKubeletServerCertificate) вместо статических файлов --tls-cert-file и --tls-private-key-file.

Подробнее можно почитать в разделе FAQ модуля control-plane-manager.

Проверки CNI-файлов (CIS 1.1.9 / 1.1.10)

Проверки AVD-KCV-0056 и AVD-KCV-0057 (права и владельца файлов конфигурации CNI) относятся к конфигурационному каталогу CNI — /etc/cni/net.d. Апстримный бандл trivy-checks использует команду аудита с глобом /*/cni/*, который также захватывает бинарники плагинов CNI в /opt/cni/bin (обязательно 755, иначе они не исполняемые) и IPAM-state в /var/lib/cni/networks (обычные файлы без секретов). На любом штатном кластере это приводит к FAIL без указания файла, который надо чинить.

DKP поставляет локальный override (images/operator/overrides/commands/kubernetes/containerNetworkInterfaceFile*.yaml), который ограничивает аудит каталогом /etc/cni/net.d — проверка отражает реальную рекомендацию CIS.

Admission plugin AlwaysPullImages (CIS 1.2.12)

Проверка AVD-KCV-0012 исторически требует --enable-admission-plugins=AlwaysPullImages на kube-apiserver. Этот admission plugin защищал от сценария «утечки через image-cache»: под в неймспейсе B мог запустить образ, который под в неймспейсе A заранее скачал с приватными credential’ами, поскольку локальный кэш kubelet делает повторный pull необязательным.

Начиная с Kubernetes 1.35 та же проблема решается на стороне kubelet через фичагейт KubeletEnsureSecretPulledImages (alpha в 1.33–1.34, beta-default в 1.35+). Kubelet перепроверяет авторизацию образа против секретов запрашивающего пода даже для предварительно скачанных образов — без постоянного трафика повторного pull’а, который порождает AlwaysPullImages. Deckhouse поддерживает Kubernetes 1.31–1.35; в 1.35 фичагейт включён по умолчанию.

DKP поставляет локальный override (images/operator/overrides/policies/kubernetes/policies/apiserver_always_pull_images_plugin.rego), который автоматически PASS-ит проверку на Kubernetes 1.35+ независимо от admission plugin’а apiserver, и возвращается к исходной логике на 1.31–1.34. Минорная версия Kubernetes определяется из тега образа kube-apiserver (например, :v1.35.3). Если тег не распознан — override прозрачен и работает исходная логика.

Отображаемое название и описание контроля в CIS-отчёте соответственно обновлены на «Авторизация образа проверяется для каждого пода (AlwaysPullImages или KubeletEnsureSecretPulledImages)».

Владелец каталога данных etcd (CIS 1.1.12)

Проверка AVD-KCV-0059 в upstream требует, чтобы каталог данных etcd /var/lib/etcd принадлежал etcd:etcd. В DKP control plane работает как статические поды под root, поэтому /var/lib/etcd принадлежит root:root. Это не нарушение: root:root не менее ограничителен, чем etcd:etcd — читать базу может только root, а root и так самый привилегированный субъект на узле.

Более того, root:root здесь безопаснее. Требование etcd:etcd означало бы заведение отдельного пользователя и группы etcd на каждом master-узле и передачу этой группе владения каталогом, в котором лежит всё хранилище секретов кластера (Secret’ы, токены, весь keyspace etcd). Это добавляет лишний непривилегированный субъект с доступом к самым чувствительным данным кластера, не улучшая изоляцию на control plane из статических подов.

DKP поставляет локальный override (images/operator/overrides/policies/kubernetes/policies/etcd_data_directory_ownership.rego), который PASS-ит проверку, если каталог данных принадлежит root:root либо etcd:etcd. Отображаемое название и описание контроля в CIS-отчёте соответственно обновлены.

Ручные проверки

Следующие проверки требуют ручной верификации и не автоматизированы. Это соответствует оригинальной спецификации CIS Benchmark, где они помечены как Manual.

Доработки Deckhouse

Отчёт CIS в DKP не совпадает с тем, что выдаёт «голый» trivy-operator. Апстримный бандл trivy-checks зафиксирован на k8s-cis-1.23; без локальных доработок проверка кластера велась бы по спецификации четырёхлетней давности. Модуль шипит набор оверлеев, которые закрывают этот разрыв. Каждый оверлей — обычный YAML/Rego в images/operator/overrides/, накладывается поверх апстримного бандла на этапе сборки образа. Читаемо, ревью-делается и снимается одной строкой, как только апстрим выкатит свой фикс.

Что доработано

• Спецификация поднята до v1.12. Файл templates/reports/cis.yaml — наш source of truth для ClusterComplianceReport. В нём перечислен 131 контроль в нумерации v1.12 (против 116 в v1.23), сохранены идентификаторы AVD-KCV / CMD из апстрима там, где audit-логика не менялась, и перенумерованы контроли по картам переименований (например, секция 5.7 в v1.12 стала 5.6).
• CIS 1.1.9 / 1.1.10 — проверки CNI-файлов. Апстримный глоб /*/cni/* захватывает бинарники плагинов в /opt/cni/bin и IPAM-state в /var/lib/cni/networks наряду с реальной конфигурацией CNI в /etc/cni/net.d. Оверлей ограничивает аудит только /etc/cni/net.d. Подробности — в разделе Проверки CNI-файлов.
• CIS 1.2.11 — AlwaysPullImages. Исходное требование (admission plugin AlwaysPullImages) удовлетворяется на уровне kubelet через фичагейт KubeletEnsureSecretPulledImages (beta-default с Kubernetes 1.35). Оверлей принимает любой из двух механизмов. Подробности — в разделе Admission plugin AlwaysPullImages.
• CIS 1.1.12 — владелец каталога данных etcd. Upstream требует etcd:etcd; etcd в DKP работает как статический под под root, поэтому /var/lib/etcd — это root:root — не менее ограничительно и предпочтительнее, так как не добавляет отдельного субъекта с доступом к хранилищу секретов кластера. Оверлей принимает root:root либо etcd:etcd. Подробности — в разделе Владелец каталога данных etcd.
• CIS 4.3.1 — kube-proxy metrics на localhost. Новый автоматический контроль в v1.12, который апстримный trivy-checks не реализует. DKP шипит AVD-KCV-0801 в своём приватном диапазоне 0801..0899; Rego срабатывает только когда kube-proxy присутствует и --metrics-bind-address указывает на не-localhost адрес. При работе с Cilium kubeProxyReplacement (дефолт в Deckhouse при использовании Cilium) DaemonSet’а kube-proxy нет вообще, правило не активируется, проверка проходит естественно.
• tools/cis-converter. Одноразовый Python-скрипт, который обновляет templates/reports/cis.yaml под соответствующий профиль aquasecurity/kube-bench (cfg/cis-X.Y). Сохраняет идентификаторы AVD-KCV и русские переводы при переименованиях; flagged-коллизии и rename-map для каждой версии в tools/cis-converter/renames/ делают каскадные переименования безопасными. Запускается при выходе очередной версии CIS в kube-bench.

Зарезервированные диапазоны идентификаторов

Чтобы не сталкиваться с будущими апстримными добавлениями, DKP-собственные проверки живут в выделенных диапазонах:

Самопроверка через kube-bench

Если хочется получить второе мнение против канонического CIS-аудита, можно запустить kube-bench как разовый Kubernetes Job рядом с кластером. kube-bench — тоже от Aqua Security и обновляется под новые версии CIS быстрее, чем trivy-checks, поэтому это самое близкое к ground-truth сравнение.

Минимальный запуск на мастер-ноде:

apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench-master
  namespace: kube-system
spec:
  template:
    spec:
      hostPID: true
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
      containers:
      - name: kube-bench
        image: aquasec/kube-bench:latest
        # Перебить профиль, если автодетект kube-bench подберёт не тот,
        # что заявлен в заголовке отчёта.
        command: ["kube-bench", "--benchmark", "cis-1.12", "run", "--targets", "master,etcd,controlplane,policies"]
        volumeMounts:
        - { name: var-lib-etcd,    mountPath: /var/lib/etcd,    readOnly: true }
        - { name: var-lib-kubelet, mountPath: /var/lib/kubelet, readOnly: true }
        - { name: etc-systemd,     mountPath: /etc/systemd,     readOnly: true }
        - { name: etc-kubernetes,  mountPath: /etc/kubernetes,  readOnly: true }
        - { name: usr-bin,         mountPath: /usr/local/mount-from-host/bin, readOnly: true }
      restartPolicy: Never
      volumes:
      - { name: var-lib-etcd,    hostPath: { path: /var/lib/etcd } }
      - { name: var-lib-kubelet, hostPath: { path: /var/lib/kubelet } }
      - { name: etc-systemd,     hostPath: { path: /etc/systemd } }
      - { name: etc-kubernetes,  hostPath: { path: /etc/kubernetes } }
      - { name: usr-bin,         hostPath: { path: /usr/bin } }
  backoffLimit: 0

d8 k apply -f kube-bench-master.yaml
d8 k -n kube-system logs job/kube-bench-master | tee kube-bench-master.txt

Для воркер-нод поменяйте nodeSelector и список таргетов (--targets node), запускайте как DaemonSet (или Job на каждую ноду). Aqua публикует готовые манифесты в kube-bench/job.yaml.

Сравнение результатов kube-bench и DKP

kube-bench и CIS-отчёт DKP используют одни и те же идентификаторы контролей (1.1.9, 4.3.1, …), поэтому сравнить их легко side-by-side. Ожидаемые расхождения:

Если видите расхождение, не указанное в этой таблице — это потенциальный баг, заводите issue на operator-trivy с обоими отчётами.

Сопоставление с kube-bench

DKP использует Trivy Operator для проверок CIS вместо утилиты kube-bench. Соответствие проверок:

Для сопоставления результатов используйте CIS Control ID (например, 1.2.1, 5.2.2).

Просмотр результатов

Grafana

Результаты проверок доступны на дашборде Security / CIS Kubernetes Benchmark.

Командная строка

Получить все результаты:

d8 k get clustercompliancereports.aquasecurity.github.io cis -ojson | \
  jq '.status.detailReport.results'

Получить только проваленные проверки:

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

Получить результат конкретной проверки:

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

Расписание проверок

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

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