Leer un informe de kube-bench

kube-bench marca cada comprobación con un estado. PASS significa que la configuración cumple lo que pide el control. FAIL significa que no lo cumple. WARN significa que la herramienta no puede decidirlo sola y pide revisión manual: son comprobaciones de criterio, no de valor. INFO es información de contexto que no se cuenta como cumplimiento ni como fallo.

El error clásico al leer el resumen es mirar solo el conteo de FAIL. Un informe con cero FAIL y muchos WARN no dice «todo bien»: dice «lo automático pasó y lo demás nadie lo ha mirado».

Cada línea del informe lleva el estado, el identificador del control y su texto. El identificador agrupa por sección (en el informe del nodo, la sección 4 es la del nodo trabajador y su configuración del kubelet) y sirve para citar el hallazgo en un ticket y para buscar su remediación. Como la numeración cambia entre versiones del benchmark, en el ticket se escribe también el texto del control.

Abre el informe del nodo y localiza el control que falla sobre las peticiones anónimas al kubelet.

El resumen del informe da el conteo por estado, pero quien decide el trabajo pendiente suma lo que no está en PASS ni en INFO: los FAIL, que hay que corregir, y los WARN, que hay que revisar. La cifra que importa para planificar es esa suma, no el total de comprobaciones.

Lee el resumen del informe del nodo y calcula cuántas comprobaciones requieren acción (de corrección o de revisión).

El informe incluye una sección de remediaciones: para cada FAIL (y algunos WARN) indica qué cambiar y dónde. Es el puente entre el hallazgo y el cambio de configuración, pero no es una orden ciega: se lee, se contrasta con cómo se despliega el nodo (un archivo de configuración o un parámetro de arranque) y el cambio se hace por el camino normal de cambios, no a mano en el nodo.

Busca la remediación del control del puerto de solo lectura del kubelet.

Un informe de kube-bench describe lo que se corrió y dónde. El del nodo trabajador evalúa la configuración de los componentes que viven en ese nodo (el kubelet y sus archivos). No evalúa el servidor de API ni el resto del plano de control, que se comprueban en los nodos del plano de control, ni evalúa los otros nodos si no se corrió allí.

Abre la nota del equipo sobre cómo se corrió el análisis.