Autenticación de cargas con identidad de servicio

Si una aplicación necesita una contraseña para pedirle contraseñas al gestor, el problema se ha movido de sitio, no resuelto. A eso se le llama a veces el problema del secreto cero. La salida es que la propia plataforma dé una identidad a la carga: un pod de Kubernetes recibe un token de su cuenta de servicio, y el gestor lo valida contra la plataforma. La aplicación no guarda nada que se pueda copiar a un archivo.

Cuando eso no es posible, como en un pipeline fuera de la plataforma, el método AppRole divide la credencial en dos mitades: un role_id que identifica al rol y un secret_id que se entrega a la carga por separado, con vida corta y pocos usos.

Un secret_id de AppRole es de usar y tirar si el rol está bien configurado: vida corta (secret_id_ttl), pocos usos (secret_id_num_uses) y una red de origen permitida (CIDR). Con un cero en vida y usos, y sin red permitida, el secret_id se convierte en una contraseña eterna que sirve desde cualquier parte.

Abre roles-approle.txt. Fíjate en los tres controles de cada rol.

En el método de Kubernetes, un rol dice qué cuentas de servicio y de qué espacios de nombres pueden autenticarse y con qué políticas. Un asterisco en la cuenta o en el espacio de nombres hace que cualquier pod de cualquier parte del clúster pueda tomar el rol. Que lo pueda tomar no quiere decir que deba: los espacios de nombres suelen ser equipos distintos.

Lee roles-kubernetes.txt y mira qué política concede cada rol.

El archivo secret-ids.txt lista los secret_id emitidos por su accesor, un identificador que permite gestionarlos sin ver su valor. Los hay usados y vencidos, sin usar y vencidos, revocados y vigentes. Un secret_id vigente de un rol sin caducidad es una llave que sigue abriendo.

Cuenta los secret_id del rol del apartado 2 que siguen vigentes (sin contar los revocados).

El rol sin límites lo usa un proceso antiguo de nómina. Cerrarlo de golpe lo rompe. Una corrección razonable endurece lo que se pueda sin cambiar la aplicación: vida corta y uso único para el secret_id, una red de origen permitida y una entrega a la carga que no deje el valor en un archivo, mientras se planea migrar el proceso a la identidad de la plataforma.