O que Benchmarking Kubernetes com kube-bench faz?
Visão Geral
kube-bench (da Aqua Security) é uma ferramenta open-source que verifica se um cluster Kubernetes está implantado de forma segura, executando as verificações documentadas no CIS Kubernetes Benchmark. Ela inspeciona os componentes do plano de controle (API server, controller manager, scheduler, etcd), a configuração do kubelet e dos nós worker, e as configurações de política de todo o cluster, reportando cada verificação como PASS, FAIL, WARN ou INFO, com uma recomendação de remediação diretamente extraída da orientação CIS. Os testes são arquivos YAML orientados por configuração, portanto o kube-bench acompanha novas versões do Kubernetes e revisões do benchmark, suportando distribuições gerenciadas (EKS, GKE, AKS, ACK, OpenShift, RKE, k3s).
Endurecer um cluster contra o CIS Benchmark reduz diretamente a superfície de ataque para T1610 (Deploy Container), onde um adversário implanta um contêiner para executar código ou evadir defesas — por exemplo, abusando de contêineres privilegiados, namespaces do host, acesso anônimo à API ou configurações inseguras do kubelet que um cluster não endurecido deixa exposto.
kube-bench pode ser executado como um binário standalone em um nó, dentro de um contêiner ou — mais comumente — como um Job Kubernetes cujo pod tem o sistema de arquivos do host montado para que possa ler os arquivos de configuração relevantes. A saída está disponível como texto legível por humanos, JSON, JUnit ou AWS Security Finding Format (ASFF) e pode ser enviada para um banco de dados PostgreSQL para análise de tendências.
Quando Usar
- Ao estabelecer uma linha de base de segurança para um novo cluster Kubernetes contra o CIS Kubernetes Benchmark.
- Ao realizar auditorias periódicas de conformidade do plano de controle e endurecimento de nós.
- Ao validar a remediação após aplicar alterações de hardening (re-executar para confirmar que as verificações agora estão como PASS).
- Ao integrar a varredura de conformidade do cluster em CI/CD ou em um pipeline de monitoramento contínuo.
- Ao preparar evidências para SOC 2, PCI DSS ou conformidade de hardening interna.
Pré-requisitos
- Acesso ao cluster: acesso SSH a um nó de plano de controle/worker (modo binário) ou
kubectlcom permissão para criar Jobs (modo in-cluster). - Conhecimento da versão do Kubernetes do cluster (o kube-bench detecta automaticamente, ou especifique com
--version/--benchmark). - Instalar o kube-bench (métodos oficiais da Aqua Security):
# Binary release (Linux)
KB_VERSION=0.10.7
curl -L -o kube-bench.tgz \
"https://github.com/aquasecurity/kube-bench/releases/download/v${KB_VERSION}/kube-bench_${KB_VERSION}_linux_amd64.tar.gz"
tar -xzf kube-bench.tgz
sudo mv kube-bench /usr/local/bin/
sudo cp -R cfg /etc/kube-bench/cfg
# Via Go install
go install github.com/aquasecurity/kube-bench@latest
# Executar como contêiner único diretamente em um nó (monta config do host)
docker run --rm --pid=host \
-v /etc:/etc:ro -v /var:/var:ro \
-t docker.io/aquasec/kube-bench:latest run --targets node
# Verificar
kube-bench version
Objetivos
- Executar o kube-bench contra o benchmark apropriado para a versão do Kubernetes do cluster.
- Escanear plano de controle (master), nó, etcd, políticas do plano de controle e alvos de serviço gerenciado.
- Produzir saída JSON/JUnit legível por máquina para pipelines e dashboards.
- Triar resultados FAIL e WARN e aplicar as orientações de remediação do CIS.
- Re-executar para validar que as correções agora estão como PASS.
Mapeamento MITRE ATT&CK
| ID da Técnica | Nome | Tática | Relevância |
|---|---|---|---|
| T1610 | Deploy Container | Execução / Evasão de Defesa | O endurecimento do CIS Benchmark, aplicado pelo kube-bench, restringe implantações privilegiadas/de namespace de host, acesso anônimo à API e configurações inseguras do kubelet que adversários abusam ao implantar contêineres maliciosos. |
Fluxo de Trabalho
1. Executar a varredura padrão (detecção automática)
Executar todos os alvos aplicáveis, deixando o kube-bench detectar a versão do Kubernetes e o benchmark:
sudo kube-bench
2. Executar como um Job Kubernetes (in-cluster)
Aplicar o manifesto de Job fornecido do repositório kube-bench e ler os resultados dos logs do pod:
# Job de propósito geral
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
# Aguardar e depois recuperar os resultados
kubectl get pods -l app=kube-bench
kubectl logs -l app=kube-bench
# Jobs específicos de plataforma estão disponíveis, ex.: EKS:
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
3. Direcionar componentes específicos
Usar run --targets para escopar a varredura para grupos de componentes específicos:
# Plano de controle (API server, scheduler, controller manager)
sudo kube-bench run --targets master
# Nó worker (kubelet, proxy)
sudo kube-bench run --targets node
# Datastore etcd
sudo kube-bench run --targets etcd
# Políticas de todo o cluster (RBAC, segurança de pod, política de rede)
sudo kube-bench run --targets policies
# Combinar múltiplos alvos
sudo kube-bench run --targets master,node,etcd,policies
4. Fixar um benchmark específico ou versão do Kubernetes
Quando a detecção automática estiver errada ou você precisar auditar contra uma revisão específica, fixe o benchmark explicitamente:
# Fixar uma revisão específica do CIS benchmark
sudo kube-bench run --benchmark cis-1.8
# Ou mapear pela versão do Kubernetes
sudo kube-bench --version 1.27
# Benchmarks específicos de distribuições gerenciadas
sudo kube-bench run --benchmark eks-1.5.0
sudo kube-bench run --benchmark gke-1.6.0
sudo kube-bench run --benchmark rke2-cis-1.7
5. Executar ou pular verificações individuais
Focar em ou excluir IDs de verificação específicos durante ciclos de remediação:
# Executar apenas verificações específicas
sudo kube-bench run --targets master --check 1.2.1,1.2.2
# Pular verificações ruidosas/aceitas como conhecidas
sudo kube-bench run --targets node --skip 4.2.6
6. Produzir saída legível por máquina
Emitir JSON ou JUnit para ingestão em pipelines, SIEM ou dashboards, e gravar em um arquivo:
# JSON para um arquivo
sudo kube-bench run --targets master,node --json --outputfile kube-bench-report.json
# JUnit (para relatórios de teste em CI)
sudo kube-bench --junit --outputfile kube-bench-junit.xml
# AWS Security Finding Format (para Security Hub)
sudo kube-bench run --targets node --asff
7. Triar e remediar descobertas FAIL/WARN
Cada verificação com falha imprime uma remediação. Aplique a correção recomendada pelo CIS no nó/manifesto, por exemplo, apertando as flags do API server no manifesto do pod estático:
# Exemplo de remediação para um FAIL comum no plano de controle:
# CIS 1.2.x — garantir que anonymous-auth esteja desabilitado no API server.
# Editar o manifesto do pod estático e definir a flag:
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
# - --anonymous-auth=false
# O kubelet reinicia o pod estático automaticamente.
# Exemplo de remediação de nó — permissões do arquivo de configuração do kubelet (CIS 4.1.x):
sudo chmod 600 /etc/kubernetes/kubelet/kubelet-config.json
sudo chown root:root /etc/kubernetes/kubelet/kubelet-config.json
8. Re-validar após a remediação
Re-executar o alvo relevante e confirmar que as verificações que falhavam anteriormente agora estão como PASS, depois acompanhar a pontuação ao longo do tempo:
sudo kube-bench run --targets master --check 1.2.1 --json --outputfile recheck.json
# Opcional: persistir resultados em PostgreSQL para análise de tendências
sudo kube-bench run --targets master,node --pgsql
Ferramentas e Recursos
| Ferramenta / Recurso | Propósito | Link |
|---|---|---|
| kube-bench | Verificador do CIS Kubernetes Benchmark | https://github.com/aquasecurity/kube-bench |
| docs do kube-bench | Execução / plataformas / flags | https://aquasecurity.github.io/kube-bench/ |
| CIS Kubernetes Benchmark | Padrão de hardening de origem | https://www.cisecurity.org/benchmark/kubernetes |
| Trivy Operator | Conformidade contínua in-cluster + varredura de vulnerabilidades | https://github.com/aquasecurity/trivy-operator |
| kube-hunter | Ferramenta complementar de teste de penetração | https://github.com/aquasecurity/kube-hunter |
Critérios de Validação
- kube-bench instalado (
kube-bench version) ou executando como um Job. - Varredura executada contra o benchmark correto para a versão do Kubernetes do cluster.
- Alvos master, node, etcd e policies escaneados cada um.
- Saída JSON/JUnit produzida para ingestão em pipeline/dashboard.
- Descobertas FAIL e WARN triadas e priorizadas.
- Remediação CIS aplicada aos manifestos do plano de controle e configs dos nós.
- Re-execução confirma que verificações que falhavam anteriormente agora estão como PASS.
- Resultados rastreados ao longo do tempo (arquivo ou PostgreSQL).