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

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

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

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

Набор проверок aquasecurity/trivy-checks из исходного проекта содержит спецификацию k8s-cis-1.23. DP добавляет контроли CIS Kubernetes Benchmark v1.12 и изменяет часть проверок, как описано в разделе «Доработки DP».

Модуль использует следующие версии компонентов:

Таблица содержит версии текущего релиза модуля. Чтобы узнать образы, которые запущены в конкретном кластере, выполните:

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 сгруппированы по следующим категориям:

Исключения

В DP часть проверок отключена или исключена из отчётов. Это обусловлено архитектурными особенностями платформы и требованиями к работе системных компонентов.

Неймспейсы и объекты, исключённые из отчётов

Параметр complianceReports.skipSystemResources исключает объекты платформы из отчётов о соответствии. При значении по умолчанию true модуль применяет следующие фильтры:

• отчёты ConfigAuditReport и RbacAssessmentReport не создаются в неймспейсах d8-*, kube-* и default;
• пропускаются cluster-wide-объекты с лейблом heritage=deckhouse или kubernetes.io/bootstrapping=rbac-defaults, например ClusterRole модулей DP и встроенные роли Kubernetes, такие как cluster-admin.

На отчёт InfraAssessmentReport фильтры не распространяются, поэтому проверки раздела CIS 1.x по-прежнему охватывают компоненты control plane в kube-system. Поскольку объекты в неймспейсе default не проверяются, контроль 5.6.4 (неймспейс default) не находит в нём объектов.

Чтобы исключить неймспейс из отчётов о соответствии независимо от значения параметра, добавьте ему лейбл security.deckhouse.io/skip-compliance=true:

d8 k label namespace <NAMESPACE> security.deckhouse.io/skip-compliance=true

<NAMESPACE> — имя неймспейса. В неймспейсе с этим лейблом отчёты ConfigAuditReport и RbacAssessmentReport не создаются.

Описанные ниже исключения для системных неймспейсов и неймспейса default, а также примеры ролей DP имеют значение, если complianceReports.skipSystemResources равен false.

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

Следующая проверка отключена для всех объектов кластера.

CIS 1.2.1 — анонимная аутентификация (AVD-KCV-0001)

Проверка: Аргумент --anonymous-auth установлен в false.

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

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

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

Следующие проверки отключены для объектов в неймспейсе kube-system и в неймспейсах с префиксом d8-, которые используют модули DP. В остальных неймспейсах эти проверки выполняются в полном объёме и помогают выявить небезопасные конфигурации.

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

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

Следующие исключения действуют для отдельных объектов.

CIS 5.6.4 — неймспейс default (AVD-KSV-0110)

Проверка: Не использовать неймспейс default.

Исключение: Service kubernetes в неймспейсе default (default/service-kubernetes).

Причина: Service kubernetes в неймспейсе default — встроенный сервис API-сервера Kubernetes. Kubernetes создаёт его при инициализации кластера, и переместить его в другой неймспейс нельзя.

Контекст безопасности (AVD-KSV-0020, AVD-KSV-0021)

Проверки: AVD-KSV-0020 (UID не больше 10000) и AVD-KSV-0021 (GID не больше 10000) в ConfigAuditReport. В отчёт CIS они не входят: контроль CIS 5.6.3 о контексте безопасности проверяется вручную, см. Ручные проверки.

Исключение: AVD-KSV-0020 и AVD-KSV-0021 для ReplicaSet в неймспейсах d8-*.

Причина: Эти проверки требуют, чтобы runAsUser и runAsGroup были больше 10000. Часть системных рабочих нагрузок DP запускается от root или не задаёт runAsUser и runAsGroup, потому что работает с файлами хоста и с томами, права на которые уже настроены.

Исключение имеет значение, только если параметр complianceReports.skipSystemResources равен false. При значении по умолчанию отчёты в неймспейсах d8-* не создаются вовсе, подробнее — в разделе «Неймспейсы и объекты, исключённые из отчётов».

Чтобы вывести рабочие нагрузки в системных неймспейсах, у которых в поде или контейнере runAsUser или runAsGroup не больше 10000, выполните:

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-метриках. Благодаря этому метрики отражают реальные проблемы безопасности, а не ложные срабатывания.

CIS 5.1.2 — доступ к секретам (AVD-KSV-0041)

Проверка: Минимизация доступа к Secrets.

Что проверяет: Находит ClusterRole, которые разрешают над ресурсом secrets любую из операций get, list, watch, create, update, patch, delete, deletecollection, impersonate или *.

Почему исключена из метрик: В CIS Benchmark эта рекомендация помечена как Manual. Легитимность доступа к секретам невозможно определить автоматически: такой доступ нужен любому контроллеру, который работает с TLS-сертификатами или учётными данными.

Примеры ClusterRole DP с легитимным доступом к секретам:

• d8:ingress-nginx:kruise-role — управление секретами для Ingress-контроллеров;
• d8:node-manager:machine-controller-manager — чтение секретов и ConfigMap для machine-controller-manager в неймспейсе d8-cloud-instance-manager;
• d8:operator-prometheus — чтение и создание секретов для оператора Prometheus.

Чтобы получить список ClusterRole с доступом к секретам, выполните:

d8 k get clusterroles -o json | jq -r '
  .items[]
  | select(any(.rules[]?;
      ((.resources // []) | index("secrets")) != null
      and any((.verbs // [])[];
        IN("get", "list", "watch", "create", "update", "patch", "delete", "deletecollection", "impersonate", "*"))
    ))
  | .metadata.name'

Чтобы получить привязки роли, например d8:operator-prometheus, выполните:

role_name="d8:operator-prometheus"
d8 k get clusterrolebindings,rolebindings -A | grep -F "$role_name"

Чтобы получить результаты контроля из отчёта, выполните:

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

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

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

CIS 5.1.3 — использование wildcard в ролях (AVD-KSV-0044, AVD-KSV-0045, AVD-KSV-0046)

Проверка: Минимизация использования wildcard в Role и ClusterRole.

Что проверяет: Находит Role и ClusterRole, которые разрешают операцию * над всеми ресурсами всех API-групп или над чувствительными ресурсами, такими как secrets, pods и clusterroles, а также ClusterRole, которые разрешают доступ ко всем ресурсам (*).

Почему исключена из метрик: В CIS Benchmark эта рекомендация помечена как Manual. Стандартная роль Kubernetes cluster-admin содержит wildcard, а операторам часто нужен широкий доступ для управления разнообразными ресурсами.

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

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

Чтобы получить результаты контроля из отчёта, выполните:

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

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

• встроенные роли Kubernetes, такие как cluster-admin;
• роли компонентов DP (ClusterRole с префиксом d8: и Role в неймспейсах d8-*);
• роли известных операторов.

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

Следующие проверки работают иначе, чем в наборе trivy-checks из исходного проекта, или могут не проходить в кластере DP.

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

Проверки AVD-KCV-0088 и AVD-KCV-0089 могут показывать статус FAIL. Это ожидаемое поведение: DP использует автоматическую ротацию сертификатов 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 в /var/lib/cni/networks (обычные файлы без секретов). В штатном кластере это приводит к FAIL без указания файла, который нужно исправить.

DP изменяет исходную проверку так, что аудит охватывает только /etc/cni/net.d, как требует рекомендация CIS.

Admission-плагин AlwaysPullImages (CIS 1.2.11)

Исходная проверка AVD-KCV-0012 требует --enable-admission-plugins=AlwaysPullImages на kube-apiserver. Этот admission-плагин не позволяет поду в неймспейсе B запустить образ, который под в неймспейсе A скачал с учётными данными приватного реестра: без плагина kubelet запускает образ из локального кеша и не скачивает его повторно.

В Kubernetes 1.35 та же угроза устраняется на стороне kubelet с помощью feature gate KubeletEnsureSecretPulledImages (alpha в 1.33–1.34, beta и включён по умолчанию в 1.35 и более новых версиях). Kubelet проверяет учётные данные для скачивания образа у запрашивающего пода даже для образов, которые уже есть на узле, без постоянного трафика повторных скачиваний, который создаёт AlwaysPullImages. Версии Kubernetes, которые поддерживает DP, перечислены на странице «Поддерживаемые версии».

DP изменяет проверку следующим образом:

• в Kubernetes 1.35 и более новых версиях проверка считается пройденной без admission-плагина;
• в более ранних версиях проверка требует AlwaysPullImages в --enable-admission-plugins. Включение feature gate kubelet KubeletEnsureSecretPulledImages не влияет на результат.

Минорная версия Kubernetes определяется по тегу образа контейнера kube-apiserver (например, :v1.35.3). Если тег не содержит версию, проверка требует admission-плагин в любой версии Kubernetes.

В CIS-отчёте контроль называется «Учётные данные для скачивания образа проверяются для каждого пода (AlwaysPullImages или KubeletEnsureSecretPulledImages)».

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

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

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

DP изменяет проверку так, что она считается пройденной, если директория данных принадлежит root:root или etcd:etcd. В CIS-отчёте контроль называется «Владелец директории данных etcd — root:root или etcd:etcd».

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

Следующие контроли не автоматизированы и требуют ручной проверки. В CIS Benchmark они помечены как Manual.

Доработки DP

CIS-отчёт в DP отличается от отчёта Trivy Operator из исходного проекта. Набор trivy-checks из исходного проекта содержит спецификацию k8s-cis-1.23, и DP изменяет поверх него спецификацию и часть проверок.

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

DP вносит следующие изменения:

• CIS Kubernetes Benchmark v1.12. CIS-отчёт содержит 131 контроль в нумерации v1.12 (в спецификации k8s-cis-1.23 из исходного проекта — 116). Контроли сохраняют идентификаторы проверок из исходного проекта там, где логика проверки не менялась. Номера контролей отличаются от исходной спецификации: например, раздел CIS 5.7 в v1.12 стал разделом 5.6.
• CIS 1.1.9 / 1.1.10 — проверки CNI-файлов. Аудит охватывает только /etc/cni/net.d. Подробности — в разделе «Проверки CNI-файлов».
• CIS 1.2.11 — AlwaysPullImages. В Kubernetes 1.35 и более новых версиях проверка считается пройденной без admission-плагина. В более ранних версиях она требует AlwaysPullImages в --enable-admission-plugins; включение feature gate kubelet KubeletEnsureSecretPulledImages не влияет на результат. Подробности — в разделе «Admission-плагин AlwaysPullImages».
• CIS 1.1.12 — владелец директории данных etcd. Проверка принимает root:root или etcd:etcd. Подробности — в разделе «Владелец директории данных etcd».
• CIS 4.3.1 — метрики kube-proxy на localhost. В trivy-checks из исходного проекта нет проверки для этого контроля v1.12. DP добавляет проверку AVD-KCV-0801. Она не проходит, если контейнер kube-proxy запущен с --metrics-bind-address, который указывает на адрес, отличный от 127.0.0.1, localhost или [::1]. Проверка читает только флаг командной строки. Параметр metricsBindAddress в файле конфигурации kube-proxy не проверяется, проверьте его вручную. С модулем cni-cilium Cilium заменяет kube-proxy (kubeProxyReplacement), DaemonSet kube-proxy отсутствует, и проверка проходит.

Проверки AVD-KCV-0801–AVD-KCV-0899 — проверки DP, которых нет в trivy-checks из исходного проекта.

Проверка с помощью kube-bench

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

Следующий Job запускает kube-bench на master-узле:

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
        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

Сохраните манифест в файл kube-bench-master.yaml и примените его:

d8 k apply -f kube-bench-master.yaml

Сохраните вывод Job в файл:

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

Чтобы проверить worker-узлы, измените nodeSelector и список целей (--targets node) и запустите Job на каждом worker-узле. В репозитории kube-bench есть готовые манифесты job-master.yaml и job-node.yaml.

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

kube-bench и CIS-отчёт DP используют одни и те же идентификаторы контролей (1.1.9, 4.3.1 и другие), поэтому их можно сравнивать по каждому контролю. В DP проверки control plane и узлов (AVD-KCV-*) выполняют команды на узлах через k8s-node-collector, а проверки политик (AVD-KSV-*) анализируют объекты Kubernetes.

Результаты различаются для следующих контролей:

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

Результаты можно посмотреть в Deckhouse Console или с помощью d8 k.

Deckhouse Console

Результаты CIS Benchmark доступны в разделе Система → Управление системой → Безопасность → Отчёты о соответствии.

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

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

d8 k get clustercompliancereports.trivy.deckhouse.io cis -ojson | jq '.status.detailReport.results'

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

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

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

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

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

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