Explica por qué los SVIDs de corta duración de SPIFFE/SPIRE dependen de la integridad del nodo, qué mostró una prueba de suplantación de cgroup en laboratorio y qué controles de Kubernetes pueden limitar el impacto.
SPIFFE proporciona a los servicios documentos criptográficos de identidad de corta duración llamados SVIDs. Las cargas de trabajo pueden utilizarlos para establecer conexiones TLS o firmar y verificar JWTs. La descripción general oficial de SPIFFE define este modelo.
Dónde se toma la decisión sobre la identidad
SPIRE realiza la atestación de los nodos y las cargas de trabajo antes de emitir SVIDs. Durante la atestación de una carga de trabajo, el agente de SPIRE determina las propiedades de un proceso a partir de fuentes locales, como el núcleo del sistema operativo o un kubelet del mismo nodo. Luego compara esas propiedades con las condiciones de los selectores de una entrada de registro; si coinciden, esa correspondencia determina qué SPIFFE ID recibe el proceso. La documentación sobre los conceptos de SPIRE describe el mecanismo.
Alcance del hallazgo de laboratorio
En este modelo, la validez criptográfica de un SVID y su emisión al proceso previsto son cuestiones distintas. La investigación de laboratorio de Unit 42 mostró que un atacante que ya tuviera acceso root a un nodo de Kubernetes podía falsear la información de cgroup de Linux, engañar al agente de SPIRE y obtener un SVID válido perteneciente a otra carga de trabajo del mismo nodo. La secuencia técnica está documentada en la investigación de Unit 42.
Unit 42 afirma expresamente que no ha observado esta técnica en ataques reales. Por tanto, el hallazgo no constituye evidencia de explotación activa; describe un riesgo posterior a la explotación que surge cuando el acceso root rompe la confianza en el nodo.
Un modelo de defensa frente al riesgo de los nodos
A efectos de la planificación defensiva, se debe tratar un nodo comprometido como si también estuvieran comprometidas todas las identidades de cargas de trabajo vinculadas a ese nodo. Las recomendaciones de Unit 42 incluyen restringir los contenedores privilegiados y el acceso directo al host, además de reducir la dependencia de selectores débiles o fáciles de suplantar. El alcance pertinente es el nodo comprometido, no automáticamente todo el clúster.
Reduzca los privilegios de los pods y los nodos
El perfil Restricted de Kubernetes Pod Security Standards exige que se prohíban los pods privilegiados, se bloquee la escalada de privilegios y los contenedores se ejecuten con usuarios distintos de root. La lista de verificación de seguridad oficial también indica que seccomp puede reducir la superficie de llamadas al sistema del núcleo de Linux disponible dentro de los contenedores. Los detalles figuran en los Pod Security Standards y en la lista de verificación de seguridad de Kubernetes.
Trate los selectores como parte del límite de confianza
Los selectores no son meros detalles de coincidencia: determinan qué propiedades locales se tienen en cuenta al decidir el resultado de la atestación. Por ello, una revisión debe considerar qué datos del sistema operativo o del kubelet alimentan cada condición y si el acceso root podría facilitar su falsificación. El objetivo es utilizar selectores que distingan las cargas de trabajo de forma precisa, en lugar de condiciones amplias o débiles.
Separe los niveles de sensibilidad y las credenciales adicionales
Kubernetes también recomienda ubicar las cargas de trabajo con distintos niveles de sensibilidad en nodos separados y no montar tokens de cuentas de servicio en pods que no los necesiten. Ambos controles se describen en la lista de verificación de seguridad oficial.
La separación de nodos busca dificultar el salto directo a aplicaciones más sensibles tras un escape de contenedor. No montar un token de cuenta de servicio innecesario también evita que haya dentro del pod una credencial adicional, distinta del SVID.
Una secuencia práctica de revisión
Este límite de confianza puede concretarse en una breve secuencia de revisión que considere conjuntamente la configuración y la ubicación de las cargas de trabajo:
Ámbito de las identidades: ¿Qué SPIFFE IDs corresponden al ámbito de cada nodo y qué niveles de sensibilidad comparten ese nodo?
Datos de entrada para la atestación: ¿Qué datos del sistema operativo o del kubelet alimentan los selectores y podría el acceso root permitir su falsificación?
Privilegios de los nodos: ¿Qué pods son privilegiados, pueden acceder al host, permiten la escalada de privilegios o se ejecutan como root?
Credenciales adicionales: ¿Qué pods reciben tokens de cuentas de servicio aunque no los necesiten?
La conclusión no es que los SVIDs carezcan de valor. Sus garantías criptográficas de identidad deben evaluarse junto con la integridad del nodo donde se realiza la atestación. Un modelo resiliente combina identidades de cargas de trabajo de corta duración con el endurecimiento de los pods, condiciones de selección precisas, la separación de nodos según la sensibilidad y la eliminación de credenciales innecesarias.
