Запускаешь kube-bench на свежем кластере kubeadm - и получаешь длинный список FAIL: права на файлы, флаги API server, настройки kubelet, отсутствие журнала аудита. Запускаешь на том же кластере Kubescape по CIS - и видишь уже другой набор проблем: RBAC, securityContext, NetworkPolicy, сервисные аккаунты, манифесты. Оба инструмента вроде бы проверяют Kubernetes по CIS Benchmark. Но отвечают на разные вопросы и смотрят на кластер с разных сторон.
Из-за этого их постоянно ставят в один ряд и ждут от них одинакового результата. Дальше начинается разочарование: один не показывает то, что команда ждала увидеть в манифестах, второй не даёт той точности, которую хотелось бы получить по control plane и worker node. Проблема не в инструментах. Проблема в ожиданиях. kube-bench и Kubescape не дублируют друг друга. Они работают на разных слоях.
Аудит Kubernetes по CIS Benchmark
CIS Kubernetes Benchmark
CIS Kubernetes Benchmark - это базовый набор рекомендаций по безопасной конфигурации кластера. Без пафоса и без лишней теории: документ нужен, чтобы быстро пройтись по типовым ошибкам, которые в Kubernetes всплывают снова и снова. Флаги запуска, права на файлы, настройки kubelet, RBAC, сетевые политики, ограничения безопасности для pod'ов, работа с секретами - всё это уже давно описано, и именно это чаще всего остаётся в кластере недокрученным.Проверки там разбиты на несколько крупных блоков:
- управляющие компоненты - API server, controller manager, scheduler, etcd;
- рабочие узлы - kubelet, kubeconfig, права на системные файлы;
- политики - RBAC, ограничения безопасности, NetworkPolicy, управление секретами.
С управляемыми кластерами отдельная история. В EKS, AKS и GKE управляющая плоскость принадлежит провайдеру, и обычный аудит control plane там невозможен. Это важная оговорка, потому что без неё сравнивать инструменты становится бессмысленно: часть проверок просто неприменима.
Зачем вообще сравнивать kube-bench и Kubescape
Оба инструмента фигурируют в разговорах про CIS, оба выдают отчёты, оба давно стоят в чеклистах Kubernetes-аудита. Отсюда и путаница. Kube-bench проверяет то, что живёт на узле: процессы, флаги, системные файлы, права доступа, локальную конфигурацию. Kubescape работает через Kubernetes API, манифесты и наборы политик. Его сильная сторона - не узел, а сами объекты кластера. На одном и том же кластере они закономерно покажут разные проблемы. И это как раз нормально.kube-bench: аудит конфигурации на уровне узла
Как устроен kube-bench
kube-bench - инструмент от Aqua Security. Его логика очень простая: взять проверку из CIS Benchmark и воспроизвести её на узле. Если в бенчмарке сказано проверить флаг kube-apiserver, kube-bench ищет процесс и разбирает параметры запуска. Если сказано проверить права на файл, он делает stat. Если нужно найти конфигурацию в конкретном месте, он идёт в этот путь и смотрит, что там реально лежит.Проверки описаны в YAML. За счёт этого сам инструмент остаётся довольно прямым, а набор правил можно обновлять под новые редакции бенчмарка и разные дистрибутивы Kubernetes.
Типичная проверка выглядит так:
YAML:
- id: 1.2.1
text: "Ensure that the --anonymous-auth argument is set to false"
audit: "/bin/ps -ef | grep kube-apiserver | grep -v grep"
tests:
test_items:
- flag: "--anonymous-auth"
compare:
op: eq
value: "false"
remediation: |
Edit the API server pod specification file
/etc/kubernetes/manifests/kube-apiserver.yaml
and set the below parameter.
--anonymous-auth=false
scored: trueУстановка: Job, DaemonSet, выбор целей
Самый привычный запуск - через Job в самом кластере:
Bash:
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-benchЕсли нужен не полный прогон, а точечная проверка, можно запускать аудит по целям:
Bash:
# Только control plane
kube-bench run --targets master
# Только worker node
kube-bench run --targets node
# Конкретный профиль бенчмарка
kube-bench run --benchmark cis-1.24Проверки: control plane, worker node, policies
Именно здесь хорошо видно, где kube-bench силён, а где уже нет.Сильная сторона:
- флаги запуска API server, controller manager, scheduler, etcd;
- права на файлы;
- конфигурация kubelet;
- локальные параметры на узле;
- всё, что видно через процессы и файловую систему.
- RBAC как система ролей и привязок;
- pod'ы и их securityContext;
- NetworkPolicy;
- манифесты до развёртывания;
- связки между объектами через API.
Форматы вывода: JSON и JUnit
С выводом у kube-bench всё прямолинейно. По умолчанию это человекочитаемый текст. Для автоматизации есть JSON и JUnit.Текстовый вывод выглядит так:
Код:
[FAIL] 1.2.6 Ensure that the --kubelet-certificate-authority argument is set (Automated)
[PASS] 1.2.7 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Automated)
[WARN] 1.2.8 Ensure that the --authorization-mode argument includes Node (Manual)Kubescape: аудит через API, политики и манифесты
Как устроен Kubescape
Kubescape смотрит на кластер иначе. Не через процессы и файлы на узле, а через Kubernetes API, манифесты и наборы политик. Это уже другой тип аудита.Если kube-bench отвечает на вопрос “что реально настроено на хосте”, то Kubescape отвечает на вопрос “какие объекты в кластере и в манифестах уже создают риск”.
Базовый запуск выглядит так:
Bash:
# Полное сканирование
kubescape scan
# Только CIS
kubescape scan framework cis-v1.23-t1.0.1
# Только NSA
kubescape scan framework nsa
# Конкретный контрол
kubescape scan control C-0005 -vФреймворки: CIS, NSA, MITRE
CIS для Kubescape - только один из наборов проверок. Помимо него есть NSA-CISA, MITRE ATT&CK for Containers и другие профили.Это не косметика. Один и тот же кластер можно смотреть как на среду, которая должна соответствовать базовым рекомендациям CIS, как на инфраструктуру, которую надо усиливать по NSA, и как на атакуемую систему, где полезно видеть риск через MITRE ATT&CK. Kubescape закрывает эти сценарии в одном инструменте.
Расширенные проверки
Kubescape заметно сильнее там, где проблема живёт не в файле на узле, а в самом объекте Kubernetes.Он глубже работает с тем, что видно через API:
- RBAC и избыточные привилегии;
- ServiceAccount и автомонтирование токенов;
- securityContext;
- запуск от root;
- privileged, hostNetwork, hostPID;
- NetworkPolicy;
- проверка YAML до развёртывания;
- анализ образов.
Head-to-Head Comparison
Coverage: кто что реально покрывает
Если говорить про control plane и worker node, kube-bench обычно точнее. Он лучше чувствует флаги, права на файлы, системную конфигурацию и всё, что живёт на уровне узла.Если говорить про RBAC, pod'ы, securityContext, NetworkPolicy, сервисные аккаунты и YAML до деплоя, сильнее выглядит Kubescape.
Поэтому вопрос “кто лучше проверяет CIS” без уточнения слоя бесполезен. Они покрывают один и тот же бенчмарк, но разными способами и на разной глубине.
Скорость выполнения
kube-bench почти всегда быстрее. Это набор локальных проверок: процессы, файлы, права доступа.Kubescape тяжелее, потому что у него больше контекста: API, объекты, политики, иногда ещё и образы. Цена охвата здесь выше.
Формат отчётов
У kube-bench отчёт сухой и прямой: PASS, FAIL, WARN, INFO, рекомендация по исправлению.У Kubescape отчёт удобнее для тех, кто чинит манифесты и объекты кластера. Он группирует замечания по контролам и ресурсам, лучше привязывает проблему к конкретному объекту, а не только к номеру проверки.
Если проблему исправляет инженер, работающий с узлом, kube-bench часто понятнее. Если проблему чинит команда, работающая с YAML и объектами через Git, удобнее Kubescape.
Extensibility
kube-bench расширяется через YAML-описания проверок. Это удобно, когда нужно добавить ещё одну проверку файла, флага или режима доступа. Порог входа невысокий, но и возможности на этом уровне заканчиваются быстро.Kubescape расширяется через политики. Порог входа выше, но и логика проверок может быть заметно сложнее: связи между объектами, собственные требования к конфигурации, внутренние правила платформы.
Интеграция в CI/CD
kube-bench в GitHub Actions
kube-bench в конвейере обычно нужен не на каждый pull request, а как периодический аудит уже работающего кластера.
YAML:
name: CIS Benchmark
on:
schedule:
- cron: '0 6 * * 1'
jobs:
kube-bench:
runs-on: self-hosted
steps:
- name: Run kube-bench
run: |
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl wait --for=condition=complete job/kube-bench --timeout=120s
kubectl logs job/kube-bench > results.txt
kubectl delete job kube-bench
- name: Upload results
uses: actions/upload-artifact@v4
with:
name: cis-benchmark
path: results.txtKubescape в GitLab CI
Kubescape как раз хорошо ложится на раннюю проверку:
YAML:
cis_scan:
stage: security
image: quay.io/kubescape/kubescape-cli:latest
script:
- kubescape scan framework cis
--format junit
--output results.xml
--compliance-threshold 80
artifacts:
reports:
junit: results.xml
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
YAML:
manifest_scan:
stage: lint
image: quay.io/kubescape/kubescape-cli:latest
script:
- kubescape scan $CI_PROJECT_DIR/k8s/
--format sarif
--output results.sarifПороги качества
У Kubescape порог качества встроен в сам запуск. Можно задать минимальный уровень соответствия и уронить конвейер, если он не достигнут.У kube-bench такой логики нет. Там придётся парсить JSON, считать количество FAIL или WARN и уже отдельно решать, что считать проходным результатом.
Исправление типовых недочетов
Пять самых частых находок
Ниже - пять замечаний, которые всплывают почти в каждом аудите.1. В API server не отключён anonymous-auth
Это одна из самых частых проблем из отчётов kube-bench. Сам по себе system:anonymous ещё не гарантирует беду, но в сочетании со слишком широкой RBAC-привязкой быстро превращается в реальный риск.
2. У kubelet слабый режим авторизации
Тут регулярно всплывает authorization-mode, который должен быть жёстче.
YAML:
authorization:
mode: WebhookЭто уже типовая территория Kubescape: запуск от root, корневая файловая система на запись, не отключено повышение привилегий, capabilities не сброшены.
YAML:
securityContext:
runAsNonRoot: true
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
drop:
- ALLПока инцидента не было, это выглядит как скучная рекомендация. После инцидента выясняется, что расследовать почти нечего.
YAML:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
resources:
- group: ""
resources: ["secrets", "configmaps"]
- level: RequestResponse
resources:
- group: "rbac.authorization.k8s.io"
resources: ["clusterroles", "clusterrolebindings"]
- level: Metadata
omitStages:
- RequestReceivedБез NetworkPolicy трафик между pod'ами часто разрешён по умолчанию. Один скомпрометированный pod быстро превращается в точку движения по кластеру.
YAML:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- IngressЧто в итоге
kube-bench и Kubescape не конкурируют напрямую. Один полезен там, где надо быстро и точно пройтись по узлу, control plane, флагам запуска и правам на файлы. Второй сильнее там, где проблема живёт в объектах Kubernetes: RBAC, securityContext, NetworkPolicy, сервисные аккаунты и манифесты до деплоя.Если нужен один практический вывод, он простой: kube-bench закрывает хостовый слой, Kubescape - слой API и декларативной конфигурации. В живом кластере этого почти всегда хватает, чтобы не спорить, какой инструмент “лучше”, а выбрать нормальную комбинацию под свою среду.
CIS Benchmark на этом не заканчивает разговор о безопасности, а только убирает самые типовые ошибки. Дальше всё упирается в то, что реально запущено в кластере, кто имеет доступ, как устроены сетевые границы и насколько быстро команда вообще увидит, что один pod однажды получил больше, чем должен.
Последнее редактирование:
