Secretos y cuentas de servicio

Un secreto de Kubernetes guarda sus valores codificados en base64, y base64 no es cifrado: se decodifica sin clave. Lo que protege al secreto es el permiso para leerlo y, si el clúster lo configura, el cifrado en reposo del almacén. Quien tiene permiso de lectura sobre un secreto, y esa persona puede ser una cuenta de servicio, lo recibe en claro.

Cada pod, además, lleva por defecto el token de su cuenta de servicio montado en un archivo. Es un token proyectado, con caducidad y renovado por el kubelet, pero mientras vive sirve para pedir al servidor de API todo lo que esa cuenta puede.

Los permisos de una cuenta se leen en sus roles y en sus vínculos. Un rol puede limitar los recursos por nombre: lo que la aplicación necesita (su propia configuración). O puede dar lectura de todos los secretos del namespace, que es mucho más de lo que ninguna aplicación necesita para funcionar.

La auditoría con nivel Metadata dice qué secreto leyó la cuenta de servicio del pod aunque el pod no lo monte. Esa diferencia, entre lo que el pod usa y lo que la cuenta leyó, es el hallazgo: una aplicación que lee los secretos que necesita no tiene por qué pedir otros.

Un secreto que pudo leerse se considera expuesto y se rota. Cuánto llevaba sin rotar da una idea de su ventana de exposición: cuanto más viejo, más tiempo pudo estar en manos de alguien. La cuenta se hace desde la última rotación hasta el día de hoy.

Cerrar una exposición de credenciales tiene un orden. Se rota el valor en el sistema que lo emitió, se actualiza el secreto, se recorta el permiso que sobraba y se verifica en el registro que el valor anterior ya no se usa. Borrar el secreto sin rotarlo rompe la aplicación y deja viva la credencial original.