Escaneo de postura del clúster y los seis hallazgos que están siempre

Lanza un escaneo de postura contra un clúster que nunca lo ha tenido y obtienes varios cientos de hallazgos. Nadie lee varios cientos de hallazgos. El informe se distribuye, se acusa recibo, se archiva, y el clúster se queda exactamente como estaba.

El escaneo sigue mereciendo la pena. El trabajo está en saber qué hallazgos importan, cuáles son ruido en tu contexto, y cómo presentar el resultado para que algo cambie.

Qué hacen las herramientas y en qué se diferencian

kube-bench comprueba un clúster contra el estándar de referencia de Kubernetes. Es enfocado, maduro y la referencia estándar, y una parte grande de sus comprobaciones se refiere a la configuración del plano de control: parámetros del servidor de API, permisos de etcd, ajustes del gestor de controladores.

Ahí está la trampa en un clúster gestionado. No controlas los parámetros del servidor de API, y el proveedor no expone los ficheros que kube-bench quiere leer. Muchas comprobaciones saldrán como no aplicables o fallarán por razones sobre las que no puedes actuar. Usa la versión del estándar específica para clústeres gestionados donde exista, y sé explícito con tu equipo sobre que la sección del plano de control es responsabilidad del proveedor, documentada en el modelo de responsabilidad compartida y no en tu lista de tareas.

Kubescape toma una vista más amplia: controles del estándar más configuración de las cargas, más correspondencias con marcos de ataque y conjuntos de controles regulatorios, con escaneo de imágenes e integración de admisión. Es más útil como vista única de la postura del clúster, y correspondientemente más ruidoso nada más instalarlo.

Los dos pertenecen al mismo conjunto que las herramientas de ocho herramientas libres para postura cloud. Ninguno sustituye a los demás: el escaneo es estático, el control de admisión previene, y la detección en tiempo de ejecución observa, que es la estratificación de Falco te dice qué hizo un contenedor.

Los seis hallazgos que están siempre

Después de suficientes clústeres, la lista deja de sorprender. Estos seis explican casi todo el riesgo real del informe.

1. Contenedores corriendo como root. El valor por defecto cuando nadie especifica otra cosa. Un escape de contenedor desde un proceso root llega al nodo como root. El arreglo es un contexto de seguridad con usuario no privilegiado, sistema de ficheros raíz de solo lectura y capacidades eliminadas, y normalmente exige un cambio en la imagen y no solo en el manifiesto.

2. Contenedores privilegiados y espacios de nombres del anfitrión compartidos. Un contenedor privilegiado es en la práctica root en el nodo. La red del anfitrión, sus procesos y los montajes de rutas del anfitrión son la misma categoría. Todos los entornos tienen unos cuantos, normalmente un agente de monitorización o una carga heredada, y cada uno necesita o una justificación registrada o su eliminación.

3. Sin política de red. Por defecto todos los pods pueden alcanzar a todos los demás en todos los namespaces, lo que hace trivial el movimiento lateral tras cualquier compromiso. Es el arreglo de más valor de la lista y el que se cubre en varios equipos en un clúster.

4. Permisos demasiado amplios. Administración de clúster asignada a un grupo que nadie ha revisado, comodines en los roles, cuentas de servicio con más de lo que necesitan. Presta atención especial al permiso de leer secretos y al de crear pods, ya que el segundo implica el primero.

5. Tokens de cuenta de servicio montados automáticamente. Se montan por defecto en todos los pods, llame la carga a la API de Kubernetes o no. Casi ninguna lo hace. Desactivar el montaje automático donde no hace falta elimina una credencial que un atacante encontraría de inmediato.

6. Acceso al extremo de metadatos de la nube. No es un control de Kubernetes y es el más trascendente de todos. Desde un pod comprometido, llegar al extremo de metadatos del nodo es la ruta clásica hacia las credenciales de la nube. Bloquéalo con una política de red y usa federación de identidad de carga de trabajo en su lugar, como en un Secret de Kubernetes es base64.

Arregla esos seis y el perfil de riesgo del clúster cambia más de lo que sugiere el número de hallazgos.

Hacer accionable el informe

La razón por la que fracasa el escaneo de postura es la presentación, no la detección.

Filtra por explotabilidad, no por etiqueta de severidad. Un hallazgo de severidad alta en una carga sin exposición de red ni datos sensibles importa menos que uno medio en tu servicio expuesto a internet. Enriquece los hallazgos con si la carga está expuesta y qué puede alcanzar.

Agrupa por arreglo, no por hallazgo. Trescientos hallazgos se resuelven con frecuencia en ocho cambios, porque la misma imagen base o el mismo chart producen el mismo hallazgo en todos los namespaces. Presentar ocho tareas consigue que se haga el trabajo; presentar trescientos hallazgos no.

Asigna por dueño del namespace. Un informe al equipo de plataforma es un informe a gente que no puede cambiar casi ninguna de las cargas. Los metadatos de propiedad que hacen esto posible son los de un portal de desarrollo vale lo que su catálogo.

Suprime con motivo y caducidad. Un riesgo aceptado es legítimo. Un riesgo aceptado sin dueño, sin justificación y sin fecha de revisión es un punto ciego permanente.

Sigue un número: el recuento de hallazgos en las seis categorías de arriba, a lo largo del tiempo. No el total, que se mueve por razones irrelevantes.

Escanea de forma continua y adelanta el arreglo

Un escaneo trimestral te dice el estado del día del escaneo. Los clústeres cambian a diario.

Ejecútalo en integración continua contra manifiestos y charts, para que una carga se compruebe antes de existir. Casi todos los seis hallazgos de arriba son visibles en el manifiesto, lo que significa que se pueden cazar en el momento de la revisión y no en un informe posterior.

Y después ejecútalo de forma continua en el clúster para lo que solo aparece en ejecución: asignaciones de permisos creadas a mano, cargas desplegadas fuera del pipeline, y deriva.

Y una vez despejado el atraso, aplica con control de admisión para que el hallazgo no pueda repetirse, que es la secuencia de auditar, avisar y aplicar de Kyverno o Gatekeeper. La admisión de seguridad de pods en nivel restringido cubre por sí sola una parte grande de estos seis y no necesita controlador adicional.

Las correspondencias de cumplimiento, usadas con cuidado

Estas herramientas mapean hallazgos a conjuntos de controles, lo que es genuinamente útil como evidencia y peligroso como objetivo.

Útil: un auditor que pregunta cómo aplicas el endurecimiento de contenedores recibe un resultado de escaneo, una política que lo aplica y un historial de ambos, lo que alimenta el modelo de un conjunto de controles para cuatro marcos.

Peligroso: un porcentaje de cumplimiento se convierte en la meta, y la forma más rápida de subirlo es suprimir hallazgos en vez de arreglarlos. La puntuación es un indicador, no un objetivo, por la misma razón que se expone en la puntuación segura no es el objetivo.

Lo que se olvida

• El escáner necesita privilegios. Lee la configuración del clúster y a veces ficheros del nodo, lo que lo convierte en una carga sensible por derecho propio.
• No aplicable es un resultado real. En clústeres gestionados, documenta qué secciones son del proveedor para que dejen de aparecer como fallos.
• Los hallazgos sin contexto engañan. La misma mala configuración en un trabajo por lotes interno y en una API pública no son el mismo riesgo.
• Los valores por defecto de los charts son la causa raíz. Arreglar un chart arregla todas sus entregas, que es por lo que agrupar por arreglo funciona.
• El escaneo no cubre la cadena de suministro. El contenido de la imagen es otra pregunta, cubierta en Trivy y Grype.

Qué hacer esta semana

Lanza una consulta en vez de un escaneo completo: lista todos los pods de producción que corren como root, y todos los pods con el token de cuenta de servicio montado automáticamente que nunca llaman a la API de Kubernetes. Esas dos listas son cortas, accionables y cubren dos de los seis. Arreglarlas es un cambio de manifiesto por carga y reduce de forma medible lo que vale un compromiso. Arrancamos la línea de endurecimiento de clúster de un proyecto de seguridad con exactamente esas dos listas.