Benchmarking de Kubernetes con kube-bench
Descripción general
kube-bench (de Aqua Security) es una herramienta de código abierto que verifica si un clúster de Kubernetes está desplegado de forma segura ejecutando las comprobaciones documentadas en el CIS Kubernetes Benchmark. Inspecciona los componentes del plano de control (API server, controller manager, scheduler, etcd), la configuración del kubelet y los nodos trabajadores, así como las políticas globales del clúster, reportando cada verificación como PASS, FAIL, WARN o INFO, junto con una recomendación de remediación basada directamente en las guías CIS. Las pruebas se definen en archivos YAML configurables, por lo que kube-bench sigue las nuevas versiones de Kubernetes y las revisiones del benchmark, y admite distribuciones gestionadas (EKS, GKE, AKS, ACK, OpenShift, RKE, k3s).
Endurecer un clúster según el CIS Benchmark reduce directamente la superficie de ataque para la técnica T1610 (Desplegar Contenedor), donde un adversario despliega un contenedor para ejecutar código o evadir defensas — por ejemplo, abusando de contenedores privilegiados, namespaces de host, acceso anónimo a la API o configuraciones inseguras del kubelet que un clúster no endurecido deja expuestas.
kube-bench puede ejecutarse como binario independiente en un nodo, dentro de un contenedor o, más comúnmente, como un Job de Kubernetes cuyo pod tiene montado el sistema de archivos del host para poder leer los archivos de configuración relevantes. La salida está disponible en formato texto legible, JSON, JUnit o AWS Security Finding Format (ASFF) y puede enviarse a una base de datos PostgreSQL para realizar un seguimiento de tendencias.
Cuándo usarlo
- Al establecer una línea base de seguridad para un nuevo clúster de Kubernetes según el CIS Kubernetes Benchmark.
- Al realizar auditorías periódicas de cumplimiento del endurecimiento del plano de control y los nodos.
- Al validar la remediación después de aplicar cambios de endurecimiento (volver a ejecutar para confirmar que las comprobaciones ahora son PASS).
- Al integrar el escaneo de cumplimiento del clúster en CI/CD o en un pipeline de monitoreo continuo.
- Al preparar evidencia para SOC 2, PCI DSS o cumplimiento de endurecimiento interno.
Requisitos previos
- Acceso al clúster: ya sea acceso SSH a un nodo del plano de control/trabajador (modo binario) o
kubectlcon permiso para crear Jobs (modo en clúster). - Conocimiento de la versión de Kubernetes del clúster (kube-bench la detecta automáticamente, o se puede especificar con
--version/--benchmark). - Instalar kube-bench (métodos oficiales de Aqua Security):
# Lanzamiento binario (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
# Mediante instalación Go
go install github.com/aquasecurity/kube-bench@latest
# Ejecutar como contenedor único directamente en un nodo (monta la configuración del 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
- Ejecutar kube-bench contra el benchmark apropiado para la versión de Kubernetes del clúster.
- Escanear el plano de control (master), nodos, etcd, políticas del plano de control y destinos de servicios gestionados.
- Producir salida JSON/JUnit legible por máquina para pipelines y paneles de control.
- Clasificar los resultados FAIL y WARN y aplicar las guías de remediación de CIS.
- Volver a ejecutar para validar que las remediaciones ahora son PASS.
Mapeo MITRE ATT&CK
| ID de Técnica | Nombre | Táctica | Relevancia |
|---|---|---|---|
| T1610 | Desplegar Contenedor | Ejecución / Evasión de Defensas | El endurecimiento del CIS Benchmark aplicado por kube-bench restringe despliegues privilegiados/de namespace de host, acceso anónimo a la API y configuraciones inseguras del kubelet que los adversarios abusan al desplegar contenedores maliciosos. |
Flujo de trabajo
1. Ejecutar el escaneo predeterminado (detección automática)
Ejecutar todos los destinos aplicables, dejando que kube-bench detecte la versión de Kubernetes y el benchmark:
sudo kube-bench
2. Ejecutar como un Job de Kubernetes (en clúster)
Aplicar el manifiesto de Job proporcionado del repositorio de kube-bench y leer los resultados de los registros del pod:
# Job de propósito general
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
# Esperar y luego recuperar resultados
kubectl get pods -l app=kube-bench
kubectl logs -l app=kube-bench
# Hay Jobs específicos para plataformas, por ejemplo EKS:
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
3. Apuntar a componentes específicos
Usar run --targets para limitar el escaneo a grupos de componentes particulares:
# Plano de control (API server, scheduler, controller manager)
sudo kube-bench run --targets master
# Nodo trabajador (kubelet, proxy)
sudo kube-bench run --targets node
# Almacén de datos etcd
sudo kube-bench run --targets etcd
# Políticas globales del clúster (RBAC, seguridad de pods, política de red)
sudo kube-bench run --targets policies
# Combinar múltiples destinos
sudo kube-bench run --targets master,node,etcd,policies
4. Fijar un benchmark específico o una versión de Kubernetes
Cuando la detección automática es incorrecta o se debe auditar contra una revisión específica, fijar el benchmark explícitamente:
# Fijar a una revisión específica del benchmark CIS
sudo kube-bench run --benchmark cis-1.8
# O mapear por versión de Kubernetes
sudo kube-bench --version 1.27
# Benchmarks específicos de distribuciones gestionadas
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. Ejecutar u omitir comprobaciones individuales
Enfocar o excluir IDs de comprobación específicos durante los ciclos de remediación:
# Ejecutar solo comprobaciones específicas
sudo kube-bench run --targets master --check 1.2.1,1.2.2
# Omitir comprobaciones ruidosas/aceptadas conocidas
sudo kube-bench run --targets node --skip 4.2.6
6. Producir salida legible por máquina
Emitir JSON o JUnit para ingestión en pipelines, SIEM o paneles de control, y escribir en un archivo:
# JSON a un archivo
sudo kube-bench run --targets master,node --json --outputfile kube-bench-report.json
# JUnit (para informes de pruebas CI)
sudo kube-bench --junit --outputfile kube-bench-junit.xml
# Formato AWS Security Finding Format (para Security Hub)
sudo kube-bench run --targets node --asff
7. Clasificar y remediar los hallazgos FAIL/WARN
Cada comprobación fallida imprime una remediación. Aplicar la solución recomendada por CIS en el nodo/manifiesto, por ejemplo, ajustando las banderas del API server en el manifiesto del pod estático:
# Ejemplo de remediación para un FAIL común del plano de control:
# CIS 1.2.x — asegurar que anonymous-auth esté deshabilitado en el API server.
# Editar el manifiesto del pod estático y establecer la bandera:
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
# - --anonymous-auth=false
# El kubelet reinicia el pod estático automáticamente.
# Ejemplo de remediación de nodo — permisos del archivo de configuración del 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 después de la remediación
Volver a ejecutar el destino relevante y confirmar que las comprobaciones previamente fallidas ahora son PASS, luego realizar un seguimiento de la puntuación a lo largo del tiempo:
sudo kube-bench run --targets master --check 1.2.1 --json --outputfile recheck.json
# Opcional: persistir resultados en PostgreSQL para seguimiento de tendencias
sudo kube-bench run --targets master,node --pgsql
Herramientas y recursos
| Herramienta / Recurso | Propósito | Enlace |
|---|---|---|
| kube-bench | Verificador del CIS Kubernetes Benchmark | https://github.com/aquasecurity/kube-bench |
| Documentación de kube-bench | Ejecución / plataformas / banderas | https://aquasecurity.github.io/kube-bench/ |
| CIS Kubernetes Benchmark | Estándar de endurecimiento fuente | https://www.cisecurity.org/benchmark/kubernetes |
| Trivy Operator | Cumplimiento continuo en clúster + escaneo de vulnerabilidades | https://github.com/aquasecurity/trivy-operator |
| kube-hunter | Herramienta complementaria de pruebas de penetración | https://github.com/aquasecurity/kube-hunter |
Criterios de validación
- kube-bench instalado (
kube-bench version) o ejecutándose como un Job. - Escaneo ejecutado contra el benchmark correcto para la versión de Kubernetes del clúster.
- Destinos master, node, etcd y policies escaneados cada uno.
- Salida JSON/JUnit producida para ingestión en pipeline/panel de control.
- Hallazgos FAIL y WARN clasificados y priorizados.
- Remediación CIS aplicada a manifiestos del plano de control y configuraciones de nodo.
- Re-ejecución confirma que las comprobaciones previamente fallidas ahora son PASS.
- Resultados registrados a lo largo del tiempo (archivo o PostgreSQL).