Saltar al contenido principal

CIS Benchmarks: auditando la seguridad del cluster

Bienvenido a la especialización CKS, la de seguridad. Y empezamos por la pregunta obligada de todo auditor: ¿cómo sé si mi cluster está bien configurado? La respuesta estándar de la industria son los CIS Benchmarks, y su herramienta de cabecera, kube-bench.

Requisito de contexto: la certificación CKS exige tener la CKA en vigor. Esta especialización asume que dominas la administración del cluster: static pods, certificados, RBAC y troubleshooting.

¿Qué son los CIS Benchmarks?​

El CIS (Center for Internet Security) es una organización sin ánimo de lucro que publica guías de configuración segura (benchmarks) para todo tipo de tecnologías: sistemas operativos, bases de datos, nubes... y Kubernetes.

El CIS Kubernetes Benchmark es un documento con cientos de comprobaciones concretas, numeradas y justificadas, agrupadas por componente:

  1. Control plane: ficheros de configuración y flags del API server, controller manager, scheduler y etcd.
  2. etcd: cifrado, certificados y acceso.
  3. Configuración del control plane: autenticación, logging de auditoría.
  4. Nodos worker: kubelet y sus ficheros.
  5. Políticas: RBAC, pod security, network policies, secrets.

Cada comprobación indica cómo auditarla y cómo remediarla. Es, literalmente, una checklist de hardening con instrucciones.

kube-bench: el benchmark automatizado​

Revisar cientos de controles a mano no escala. kube-bench, de Aqua Security, ejecuta automáticamente las comprobaciones del benchmark contra tu cluster.

La forma más práctica de ejecutarlo es como un Job en el propio cluster:

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Esperar a que termine y leer el informe
kubectl get jobs
kubectl logs job/kube-bench

También puede ejecutarse como binario directamente en un nodo (necesario para auditar el control plane si el Job no corre allí):

# En el nodo maestro
kube-bench run --targets master

# En un worker
kube-bench run --targets node

La salida clasifica cada control como [PASS], [FAIL], [WARN] o [INFO], y al final incluye la sección de remediaciones con los pasos exactos para corregir cada FAIL:

[FAIL] 1.2.16 Ensure that the --profiling argument is set to false (Automated)
...
== Remediations master ==
1.2.16 Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the control plane node and set the below parameter.
--profiling=false

Remediando hallazgos: los clásicos del examen​

En el examen CKS, el ejercicio típico es: "ejecuta kube-bench, encuentra el fallo X y corrígelo". Las remediaciones más frecuentes tocan exactamente lo que ya conoces de la especialización CKA:

En el API server (/etc/kubernetes/manifests/kube-apiserver.yaml)​

- --anonymous-auth=false            # Deshabilitar acceso anónimo
- --authorization-mode=Node,RBAC    # Nunca AlwaysAllow
- --profiling=false                 # Sin endpoint de profiling
- --enable-admission-plugins=NodeRestriction

Recuerda: es un static pod, el kubelet lo recrea al guardar. Si no vuelve, crictl ps -a y los logs, como vimos en troubleshooting.

En el kubelet (/var/lib/kubelet/config.yaml)​

El benchmark insiste especialmente en el kubelet, porque su API (puerto 10250) permite ejecutar comandos en los pods:

authentication:
  anonymous:
    enabled: false          # Nada de peticiones anónimas
  webhook:
    enabled: true           # Autenticar contra el API server
authorization:
  mode: Webhook             # Nunca AlwaysAllow
readOnlyPort: 0             # Deshabilitar el puerto de solo lectura (10255)

Tras editar: sudo systemctl restart kubelet.

En etcd​

Verificar que usa TLS y autenticación de clientes (flags --cert-file, --key-file, --client-cert-auth=true, --peer-client-cert-auth=true en su manifiesto). Un etcd accesible sin certificados regala el cluster entero: recuerda que los secrets se guardan ahí sin cifrar por defecto.

Permisos de ficheros​

Muchos controles son simples permisos:

# Los manifiestos del control plane: 644 o más restrictivos, propiedad de root
sudo chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml
sudo chown root:root /etc/kubernetes/manifests/kube-apiserver.yaml

# La clave de etcd o del kubelet: 600
sudo chmod 600 /var/lib/kubelet/config.yaml

Más allá del benchmark​

Dos matices de auditor que conviene interiorizar:

  • El benchmark es el suelo, no el techo. Pasar kube-bench al 100% no hace tu cluster invulnerable: cubre configuración, no vulnerabilidades de aplicaciones, imágenes o cadena de suministro (que veremos en los próximos capítulos).
  • Los clusters gestionados (EKS, GKE, AKS) tienen benchmarks específicos, porque el proveedor controla el control plane y muchos controles no aplican. kube-bench los soporta con --benchmark eks-1.x, etc.

Además del benchmark, la CNCF y la NSA/CISA publican sus propias guías de hardening de Kubernetes, que el examen CKS también referencia. La filosofía es la misma: minimizar superficie de ataque, mínimo privilegio y defensa en profundidad.

Resumen​

  • Los CIS Benchmarks son la checklist estándar de configuración segura; kube-bench la automatiza (job.yaml o binario por nodo).
  • Cada FAIL trae su remediación: la mayoría se arreglan editando los static pods del control plane, el config del kubelet o permisos de ficheros.
  • Los puntos calientes: anonymous-auth, authorization-mode, el kubelet (10250) y el TLS de etcd.
  • Pasar el benchmark es el punto de partida del hardening, no el final. El resto de la especialización cubre lo que el benchmark no ve.

Volver al índice