Información acerca de la rotación de secretos

La rotación de secretos es el proceso de actualizar o reemplazar periódicamente la información sensible (secretos), como contraseñas, claves de API o claves de encriptación. La rotación de secretos ayuda a minimizar el riesgo de acceso no autorizado o uso inadecuado de los secretos, en particular, si se vieron comprometidos o se filtraron.

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

  • Limita el impacto en el caso de un secreto filtrado.

  • Garantiza que las personas que ya no requieran acceso a un secreto no puedan usar valores de secretos anteriores.

  • Minimiza el riesgo de interrupciones del servicio si necesitas rotar secretos con urgencia.

Secret Manager tiene un concepto de secretos, versiones de secretos y programas de rotación, que proporcionan una base para compilar cargas de trabajo que admitan secretos rotados.

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

Antes de comenzar, te recomendamos que leas la descripción general de la plataforma para comprender el panorama general de Google Cloud. También te recomendamos que leas la descripción general del producto de Secret Manager.

Vincula una versión del Secret a tu aplicación

Un secreto en Secret Manager puede tener varias versiones. Las versiones de secretos contienen la carga útil inmutable (la cadena de bytes secreta real) y están ordenadas y numeradas. Para rotar un secreto, agrega una versión nueva a un secreto existente.

Se puede hacer referencia a la versión de secreto agregada más recientemente con el alias latest. Si bien el alias latest es conveniente para el desarrollo, puede ser problemático para algunas cargas de trabajo de producción, ya que un valor incorrecto podría lanzarse de inmediato y provocar una interrupción en todo el servicio. En las siguientes situaciones, se describen los métodos alternativos para vincularse a una versión de Secret.

Lanzamientos graduales

Los lanzamientos graduales son un principio rector para las siguientes situaciones. Si eliges un lanzamiento de secretos más lento, hay un menor riesgo de fallas, pero también un tiempo de recuperación más lento. Algunos secretos pueden invalidarse en sistemas externos (como APIs o bases de datos que hacen un seguimiento de valores secretos válidos) que pueden estar o no bajo tu control, y la recuperación en estos casos requiere un lanzamiento.

Es posible que se lance un secreto incorrecto durante la rotación manual o automática. Un flujo de trabajo de rotación sólido debería poder detectar automáticamente la falla (por ejemplo, las tasas de error de HTTP) y revertir para usar la versión anterior del secreto (a través de 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.

Enfoque 1: Solucionar el problema durante un proceso de lanzamiento existente

Resuelve y vincula tu versión secreta con la versión de lanzamiento de tu aplicación. Para la mayoría de las implementaciones, esto implica resolver la versión secreta más reciente en el nombre completo del recurso de la versión secreta y lanzarla 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, confirma en Git) y que extraigas el nombre de la versión en la configuración de la implementación durante el envío para evitar implementaciones bloqueadas.

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

Este enfoque tiene los siguientes beneficios:

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

  • Los procesos de administración de cambios existentes para los lanzamientos y las reversiones se pueden volver a usar 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.

Enfoque 2: Solucionar el problema al inicio de la aplicación

Recupera la carga útil secreta más reciente al inicio de la aplicación y continúa usando el secreto durante el tiempo que se ejecute la aplicación.

La ventaja de este enfoque es que no requiere modificar la canalización de CI/CD para resolver las versiones de secretos, pero si se implementa un secreto incorrecto, la aplicación no se inicia cuando se reinician las instancias o se escala el servicio, y podría generar una interrupción en cascada.

Enfoque 3: Soluciona de forma continua

Consulta la versión más reciente del secreto de forma continua en la aplicación y usa el valor del secreto nuevo de inmediato.

Este enfoque genera el riesgo de una interrupción inmediata en todo el servicio, ya que no se adopta de forma gradual el nuevo valor secreto.

Rota tu 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 Admin), te recomendamos que configures un trabajo de rotación que se ejecute periódicamente. Los pasos generales se describen en la siguiente sección con Cloud Run como ejemplo de entorno de procesamiento.

Configura un programa de rotación en tu secreto

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

Inicia una Cloud Run para crear una nueva versión del Secret

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 nuevo en el sistema externo (por ejemplo, la base de datos o el proveedor de la API).

    Asegúrate de que esto no invalide los secretos existentes para que las cargas de trabajo existentes no se vean afectadas.

  2. Actualiza Secret Manager con el secreto nuevo.

    Crea una nueva versión del secreto en Secret Manager. Esto también actualiza el alias latest para que apunte al secreto recién creado.

Reintentos y simultaneidad

Dado que el proceso de rotación puede finalizarse en cualquier momento, el servicio de Cloud Run debe poder reiniciar el proceso desde donde se detuvo (debe ser reentrante).

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

Para compilar una función de rotación reentrante, te puede resultar útil guardar el estado para permitir que se reanude el proceso de rotación. Existen dos funciones de Secret Manager que ayudan con esto:

  • Usa etiquetas en los secretos para guardar el estado durante la rotación. Agrega una etiqueta al secreto para hacer un seguimiento del número de la última versión agregada correctamente durante el flujo de trabajo de rotación (por ejemplo, ROTATING_TO_NEW_VERSION_NUMBER=3). Una vez que se complete la rotación, quita la etiqueta de seguimiento de rotación.

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

Permisos de Identity and Access Management

Tu proceso de rotación requiere el permiso secretmanager.versions.add para agregar una nueva versión del secreto y es posible que requiera 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 agregar una nueva versión del secreto y es posible que requiera el permiso secretmanager.versions.access para leer la versión anterior del secreto.

La cuenta de servicio predeterminada de Cloud Run tiene el rol de editor, que incluye permiso para agregar versiones secretas, pero no para acceder a ellas. Para seguir el principio de privilegio mínimo, te recomendamos no usar la cuenta de servicio predeterminada. En su lugar, configura una cuenta de servicio independiente para tu servicio de Cloud Run con los roles de Secret Manager otorgados según sea necesario (puede ser uno o varios de los siguientes):

  • roles/secretmanager.secretVersionAdder

  • roles/secretmanager.secretVersionManager

  • roles/secretmanager.secretAdmin

  • roles/secretmanager.secretAccessor

Lanza la nueva versión del Secret a las cargas de trabajo

Ahora que se registró una versión nueva y válida del secreto con el sistema externo y se almacenó en Secret Manager, impleméntala en tu aplicación. Este lanzamiento varía según tu enfoque para la vinculación de secretos y, por lo general, no requiere intervención manual.

Cómo limpiar versiones de secretos antiguas

Una vez que se quiten todas las aplicaciones de la versión anterior del secreto, se puede limpiar de forma segura. El proceso de limpieza depende del tipo de secreto, pero, en general, ocurre lo siguiente:

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

  2. Inhabilita la versión anterior del secreto en Secret Manager y verifica que las aplicaciones no fallen (espera una cantidad de tiempo razonable para permitir que una persona intervenga si la inhabilitación causa un error en un consumidor).

  3. Quita o anula el registro de la versión anterior del secreto del sistema externo.

  4. Destruye la versión anterior del secreto en Secret Manager

¿Qué sigue?