Una investigación revela que un nodo de Kubernetes puede convertirse en un punto de brecha de identidad si un atacante obtiene acceso de root. Un proceso hostil puede suplantar otras cargas de trabajo y obtener sus credenciales, expandiendo su acceso en un nodo compartido. Este problema afecta específicamente a los despliegues de SPIFFE y SPIRE, los cuales utilizan identidades de carga de trabajo de corta duración en lugar de secretos permanentes.

Un nodo de Kubernetes se convierte en un punto de brecha de identidad cuando un atacante obtiene acceso de root. Las investigaciones muestran que un proceso hostil puede suplantar otras cargas de trabajo y obtener sus credenciales, convirtiendo un único punto de apoyo en un acceso más amplio a través de un nodo compartido.

El problema afecta a los despliegues de SPIFFE y SPIRE, que sustituyen los secretos de larga duración por identidades de carga de trabajo de corta duración. Estas credenciales permiten que los servicios demuestren su identidad entre sí.

El modelo asume que el nodo es confiable, una suposición que termina cuando un atacante controla su sistema operativo. Analistas de Unit42 identificaron cómo un atacante con nivel de root puede alterar los datos de cgroup de Linux utilizados durante las comprobaciones de la carga de trabajo.

Palo Alto Networks afirmó en un informe que la técnica puede hacer que un agente local de SPIRE emita la identidad de una carga de trabajo co-ubicada a un proceso controlado por el atacante. Los investigadores dijeron que no han observado que este método se utilice en entornos reales.

Una identidad de carga de trabajo válida puede abrir rutas de confianza que las credenciales robadas ordinarias no pueden. Un atacante podría autenticarse en servicios internos, solicitar datos protegidos o moverse entre aplicaciones como si fuera un servicio legítimo.

Los casos en los que los hackers explotan configuraciones erróneas de Kubernetes muestran por qué la seguridad del nodo y los controles de identidad no pueden tratarse como problemas separados.

Un solo nodo de Kubernetes comprometido

SPIFFE asigna a cada carga de trabajo un nombre, un Documento de Identidad Verificable de SPIFFE (SVID) de corta duración y un paquete de confianza que lo valida.

Las aplicaciones solicitan un SVID al agente local de SPIRE. El agente comprueba los atributos del proceso antes de devolver una credencial para conexiones mTLS o acceso basado en tokens.

En Kubernetes, el agente puede inspeccionar la ruta del cgroup de un proceso para asociarlo con un contenedor y un pod, y luego recopilar detalles del espacio de nombres y de la cuenta de servicio.

Los compara con las reglas de registro. Cuando los valores coinciden, el agente devuelve el SVID de la carga de trabajo y el material necesario para usarlo.

Unit42 demostró que el acceso de root puede cambiar este resultado. Un atacante puede crear o manipular una ruta de cgroup que se parezca a la de un objetivo y añadir su proceso a ella. El agente puede coincidir con los selectores del objetivo y entregar su credencial al proceso hostil.

Esta es una técnica de post-explotación, no un fallo remoto que comprometa un clúster de forma independiente. Su radio de impacto puede ser grave: toda identidad de carga de trabajo en el nodo afectado debe considerarse expuesta.

Esto hace que los informes sobre una vulnerabilidad de NodeRestriction de Kubernetes que involucre nodos comprometidos sean importantes más allá del punto de entrada inicial.

Defendiendo el límite del nodo

Los investigadores crearon Spooffe, una herramienta de prueba que escanea un nodo, recrea rutas de cgroup para las cargas de trabajo en ejecución y solicita al agente local las identidades resultantes.

Ayuda a los defensores a medir la exposición tras un compromiso a nivel de administrador. También ilustra por qué las credenciales de corta duración no resuelven por sí solas los fallos de seguridad a nivel de host.

Las organizaciones deberían modelar el acceso de root en un nodo como el acceso a cada identidad criptográfica asignada a él. Esto significa proteger los nodos trabajadores con la misma urgencia que los sistemas de identidad, limitando estrictamente los privilegios de administrador y monitoreando cambios inesperados en procesos, contenedores y cgroups.

El consejo hace eco de las lecciones sobre el abuso de atacantes en configuraciones erróneas de Docker Kubernetes, donde los contenedores privilegiados pueden proporcionar una ruta directa al control del host.

Deberías bloquear los contenedores privilegiados cuando sea posible, restringir los montajes directos al host y la red del host, y controlar estrictamente el acceso a las interfaces de tiempo de ejecución de contenedores.

Las políticas de registro no deben depender únicamente de selectores que un adversario con nivel de root pueda imitar. Un diseño de política específico, la revisión regular y los controles por capas pueden evitar que una carga de trabajo comprometida se convierta en un incidente de identidad global.

Los defensores deben identificar las cargas de trabajo sensibles que comparten nodos, particularmente los servicios con amplios permisos de base de datos, nube o despliegue.

Separar las cargas de trabajo de alto valor y aplicar el principio de mínimo privilegio puede reducir el daño cuando un nodo falla. Las guías sobre cómo asegurar clústeres de producción de Kubernetes enfatizan similarmente los controles de acceso fuertes, la segmentación y el monitoreo continuo.

La lección clave es sencilla: la identidad de la carga de trabajo es tan fuerte como la máquina que la verifica. SPIFFE y SPIRE reducen la exposición de los secretos persistentes, pero no pueden preservar la separación una vez que se pierde el control de root del host.

Los planes de incidentes deben incluir la rotación de credenciales, la revisión de sesiones y una investigación sobre los servicios que aceptaron identidades emitidas desde el nodo afectado.

Fuentes:
https://cybersecuritynews.com/kubernetes-node/