Acerca de las programaciones de rotación

La rotación de secretos es el proceso de actualizar o sustituir periódicamente información sensible (secretos), como contraseñas, claves de API o claves de cifrado. La rotación de secretos ayuda a minimizar el riesgo de acceso no autorizado o uso inadecuado de los secretos, sobre todo si se han vulnerado o filtrado.

La rotación periódica ayuda de las siguientes formas:

  • Limita el impacto en caso de que se filtre una clave secreta.

  • Asegura que las personas que ya no necesitan acceder a un secreto no puedan usar valores de secretos antiguos.

  • Minimiza el riesgo de que se produzcan interrupciones del servicio si necesitas rotar secretos urgentemente.

Secret Manager tiene los conceptos de secretos, versiones de secretos y programaciones de rotación, que proporcionan una base para crear cargas de trabajo que admitan secretos rotados.

En esta página se ofrecen recomendaciones para rotar los secretos almacenados en Secret Manager. Aprenderás a hacer lo siguiente:

Antes de empezar, te recomendamos que leas el resumen de la plataforma para conocer el panorama general. Google Cloud También te recomendamos que leas el resumen del producto Secret Manager.

Vincular una versión de secreto a tu aplicación

Un secreto de Secret Manager puede tener varias versiones. Las versiones de secreto contienen la carga útil inmutable (la cadena de bytes del secreto) y están ordenadas y numeradas. Para rotar un secreto, añade una nueva versión de secreto a un secreto ya creado.

La versión de secreto más reciente de un secreto se puede consultar mediante el alias latest. El alias latest, aunque es práctico para el desarrollo, puede dar problemas en algunas cargas de trabajo de producción, ya que un valor incorrecto podría implementarse inmediatamente y provocar una interrupción en todo el servicio. En los siguientes casos prácticos se describen métodos alternativos para vincularse a una versión secreta.

Lanzamientos graduales

Las implementaciones graduales son un principio rector en los siguientes casos. Si eliges un lanzamiento de secretos más lento, habrá menos riesgo de que se produzcan fallos, pero también tardarás más en recuperarte. Algunos secretos se pueden invalidar en sistemas externos (como APIs o bases de datos que registran valores de secretos válidos) que pueden estar o no bajo tu control. En estos casos, la recuperación requiere un lanzamiento.

Es posible que se implemente una mala práctica de gestión de secretos durante la rotación manual o automática. Un flujo de trabajo de rotación seguro debe poder detectar automáticamente los fallos (por ejemplo, las tasas de errores HTTP) y volver a usar la versión anterior del secreto (mediante una implementación de configuración anterior).

El lanzamiento de la nueva versión del secreto depende de cómo se vinculen los secretos a tu aplicación.

Opción 1: Resolverlo durante un proceso de lanzamiento

Resuelve y vincula tu versión del secreto con la versión de tu aplicación. En la mayoría de las implementaciones, esto implica resolver la versión más reciente del secreto en el nombre de recurso completo de la versión del secreto e implementarla con la aplicación como una marca o en un archivo de configuración. Te recomendamos que resuelvas el nombre de la versión secreta en el momento de la rotación, que almacenes el nombre del recurso en un lugar duradero (por ejemplo, que lo confirmes en Git) y que incluyas el nombre de la versión en la configuración de la implementación durante el envío para evitar que se bloqueen las implementaciones.

Al iniciar la aplicación, llama a Secret Manager con el nombre de la versión del secreto específico para acceder al valor del secreto.

Este enfoque tiene las siguientes ventajas:

  • Tu aplicación usa la misma versión secreta en todos los reinicios, lo que aumenta la predictibilidad y reduce la complejidad operativa.

  • Los procesos de gestión de cambios que ya se utilizan para los lanzamientos y las reversiones se pueden reutilizar para la rotación de secretos y la implementación de versiones de secretos.

  • El valor se puede implementar gradualmente, lo que reduce el impacto de implementar valores incorrectos.

Método 2: Resolver al iniciar la aplicación

Obtén la carga útil secreta más reciente al iniciar la aplicación y sigue usando el secreto durante la duración de la aplicación.

La ventaja de este enfoque es que no requiere modificar el flujo de procesamiento de CI/CD para resolver las versiones de los secretos. Sin embargo, si se implementa un secreto incorrecto, la aplicación no se iniciará cuando se reinicien las instancias o se escale el servicio, lo que podría provocar una interrupción del servicio.

Método 3: Resolver continuamente

Consulta continuamente la versión más reciente del secreto en la aplicación y usa el nuevo valor del secreto inmediatamente.

Con este enfoque, se corre el riesgo de que se produzca una interrupción inmediata en todo el servicio, ya que no se adopta gradualmente el nuevo valor secreto.

Rotar un secreto

Si tu secreto se puede actualizar de forma dinámica (por ejemplo, si el sistema externo que valida el secreto proporciona una API de administrador), te recomendamos que configures un trabajo de rotación que se ejecute periódicamente. Los pasos generales se describen en la siguiente sección, en la que se usa Cloud Run como entorno de computación de ejemplo.

Configurar una programación de rotación en tu secreto

Configura una programación de rotación para tu secreto. Los temas de Pub/Sub deben configurarse en el secreto para recibir notificaciones cuando sea el momento de rotarlo. Consulta la guía Notificaciones de eventos para configurar temas en tus secretos.

Lanzar un Cloud Run para crear una versión de secreto

Crea y configura un servicio de Cloud Run para recibir notificaciones de rotación y ejecutar los pasos de rotación:

  1. Obtén o crea un secreto en el sistema externo (por ejemplo, una base de datos o un proveedor de APIs).

    Asegúrate de que no se invaliden los secretos actuales para que no se vean afectadas las cargas de trabajo.

  2. Actualiza Secret Manager con el nuevo secreto.

    Crea una versión de secreto en Secret Manager. También se actualiza el alias latest para que apunte al secreto recién creado.

Reintentos y simultaneidad

Como el proceso de rotación se puede terminar en cualquier momento, tu servicio de Cloud Run debe poder reiniciar el proceso desde donde lo dejó (debe ser reentrante).

Te recomendamos que configures los reintentos para que se puedan volver a ejecutar las rotaciones fallidas o interrumpidas. Además, configure la concurrencia máxima y las instancias máximas en su servicio de Cloud Run para minimizar la probabilidad de que las ejecuciones de rotación simultáneas interfieran entre sí.

Para crear una función de rotación reentrante, puede ser útil guardar el estado para permitir que se reanude el proceso de rotación. Hay dos funciones de Secret Manager que te ayudan a hacerlo:

  • Usa etiquetas en los secretos para guardar el estado durante la rotación. Añade una etiqueta al secreto para registrar el número de la última versión añadida correctamente durante el flujo de trabajo de rotación (por ejemplo, ROTATING_TO_NEW_VERSION_NUMBER=3). Una vez que se haya completado la rotación, quita la etiqueta de seguimiento de la rotación.

  • Usa ETags para verificar que otros procesos no estén modificando el secreto simultáneamente durante el flujo de trabajo de rotación. Consulta más información sobre los etags de secretos y versiones de secretos.

Permisos de gestión de identidades y accesos

Tu proceso de rotación requiere el permiso secretmanager.versions.add para añadir una nueva versión del secreto y puede requerir el permiso secretmanager.versions.access para leer la versión anterior del secreto.

Tu proceso de rotación requiere el permiso secretmanager.versions.add para añadir una nueva versión del secreto y puede requerir el permiso secretmanager.versions.access para leer la versión anterior del secreto.

La cuenta de servicio predeterminada de Cloud Run tiene el rol Editor, que incluye permiso para añadir versiones de secretos, pero no para acceder a ellas. Para seguir el principio de mínimos privilegios, te recomendamos que NO uses la cuenta de servicio predeterminada. En su lugar, configura una cuenta de servicio independiente para tu servicio Cloud Run con los roles de Secret Manager que necesites (puede ser uno o varios):

  • roles/secretmanager.secretVersionAdder

  • roles/secretmanager.secretVersionManager

  • roles/secretmanager.secretAdmin

  • roles/secretmanager.secretAccessor

Desplegar la nueva versión del secreto en las cargas de trabajo

Ahora que se ha registrado una nueva versión de secreto válida en el sistema externo y se ha almacenado en Secret Manager, despliégala en tu aplicación. Esta implementación varía en función de tu enfoque de la vinculación de secretos y, por lo general, no requiere intervención manual.

Limpiar versiones de secretos antiguas

Una vez que todas las aplicaciones hayan dejado de usar la versión antigua del secreto, se podrá eliminar de forma segura. El proceso de limpieza depende del tipo de secreto, pero, por lo general:

  1. Asegúrate de que la nueva versión del secreto se haya implementado por completo en todas las aplicaciones.

  2. Inhabilita la versión antigua del secreto en Secret Manager y comprueba que las aplicaciones no fallen (espera un tiempo razonable para que una persona pueda intervenir si la inhabilitación provoca un fallo en un consumidor).

  3. Elimina o anula el registro de la versión antigua del secreto del sistema externo.

  4. Eliminar la versión antigua del secreto en Secret Manager

Siguientes pasos