Secretos con Secret Manager

En Secret Manager un secreto es un contenedor con nombre y sus versiones guardan los valores. Una versión puede estar habilitada, deshabilitada o destruida. Para leer el valor de una versión hace falta el rol roles/secretmanager.secretAccessor, que se puede dar sobre un secreto concreto o sobre todo el proyecto.

La rotación tiene una trampa de nombre. Un secreto puede llevar un período de rotación y una fecha de la próxima, pero Secret Manager no cambia el valor por sí mismo: en la fecha, publica un mensaje SECRET_ROTATE en los temas de Pub/Sub que se hayan designado, y alguien debe suscribirse a ese tema, crear la versión nueva y desplegarla.

Si un secreto declara rotación pero ningún tema recibe la notificación, la rotación existe solo en el inventario: nadie será avisado. Es un hallazgo de configuración típico, porque en una revisión rápida el campo «rotación: 30 días» parece sano.

Abre el laboratorio. En secretos.txt hay una columna con los temas de notificación de cada secreto. Busca el que tiene rotación programada y ningún tema.

Dar secretAccessor sobre el proyecto entero es cómodo y es lo contrario del mínimo privilegio: quien lo recibe puede leer el valor de todos los secretos, también los que se crearán mañana. Lo correcto es concederlo por secreto, a la cuenta de servicio de la aplicación que lo usa. Fíjate que el rol de propietario también incluye acceso a secretos, mientras que los de editor y lector no.

Compara la política del proyecto con la política del secreto erp-conexion: en una, la concesión es amplia; en la otra, está acotada.

Rotar un secreto no sirve de nada si la versión anterior sigue habilitada y alguien la sigue leyendo: el valor viejo, que justo se rotó por una razón, sigue funcionando. El registro de acceso a datos de Secret Manager (un registro de auditoría que hay que tener activado) deja una línea por cada lectura, con la cuenta, la dirección, el recurso y el estado de la respuesta. Un code distinto de cero en status es una lectura que falló.

En servicios-cloud-run.txt verás qué servicio fija una versión concreta en lugar de usar la última. En el registro, cuenta cuántas veces se leyó con éxito la versión 1 de erp-conexion.

Tener Secret Manager no obliga a usarlo. La variable de entorno de un servicio puede apuntar a un secreto, que es lo correcto, o llevar el valor escrito en la configuración, que queda en el repositorio, en las exportaciones y en cualquier captura. En el laboratorio, los valores de secretos reales no existen: lo que ves es un marcador evidente que representa un valor escrito a mano.

En AWS el equivalente es AWS Secrets Manager, que sí puede rotar por su cuenta con una función, y en Azure es Key Vault. Los tres comparten el hallazgo de siempre: el secreto escrito a mano en la configuración.