Identidad de carga de trabajo sin secretos estáticos

Con un secreto estático, el servicio demuestra su identidad presentando algo que alguien le dio: si otro consigue el mismo valor, es indistinguible del servicio. La identidad de carga de trabajo invierte la pregunta: la plataforma donde corre el servicio atestigua qué es (en qué nodo corre, en qué espacio de nombres, con qué cuenta del clúster, con qué imagen) y, si coincide con un registro, le emite una credencial de corta vida. No hay nada que copiar en un archivo, porque la credencial nace en memoria y caduca en minutos u horas.

SPIFFE, un proyecto de código abierto de la CNCF, estandariza esta idea. Cada carga recibe un identificador con forma de URI dentro de un dominio de confianza (spiffe://dominio/ruta) y un documento que lo prueba, el SVID, que puede ser un certificado X.509 (útil para TLS mutuo entre servicios) o un token JWT. Las claves son de vida corta y se renuevan solas. Los proveedores de nube ofrecen el mismo patrón con sus identidades gestionadas, y muchos aceptan un token de identidad de carga para entregar credenciales temporales por federación.

No todos los servicios pueden dejar el secreto el mismo día: una máquina virtual sin atestación, una base de datos que solo acepta contraseña o un proveedor que solo admite claves de API tienen motivos, y lo correcto es registrarlos como excepciones con fecha. Lo que no tiene justificación es un servicio que corre donde la plataforma ya le daría identidad y que habla con un destino que ya acepta la federación, pero sigue con una clave guardada.

Abre el laboratorio y lee plataforma.txt y servicios.txt.

La identidad de carga de trabajo es tan buena como sus selectores: las condiciones que la carga tiene que cumplir para recibir una identidad. Si un registro solo exige el espacio de nombres, cualquier cosa que alguien lance en ese espacio recibe la identidad del servicio, con todos sus permisos. Por eso la norma de la plataforma pide al menos dos selectores, y en producción uno más.

Lee registros-de-identidad.txt contra la norma de plataforma.txt, y después cargas-por-espacio.txt.

Una identidad SPIFFE lleva el entorno en su ruta, pero eso solo protege si la política de autorización lo mira. Cuando producción y pruebas comparten el mismo dominio de confianza y la misma autoridad, la única frontera entre ellos es lo que diga cada regla. Un comodín en la parte del entorno convierte una identidad de pruebas, que es más fácil de conseguir, en una llave de producción.

Lee autorizaciones.txt y su nota final.

El certificado de identidad de la plataforma vale una hora y se renueva solo a mitad de su vida. La clave estática que encontraste en la tarea 2 se creó en 2025 y no tiene fecha de caducidad. Si un atacante se lleva cualquiera de las dos de la memoria de un contenedor, el daño posible se mide por cuánto tiempo sigue sirviendo lo robado.