Información acerca de los programas de rotación

En este tema, se presenta el concepto de rotación de secretos. Antes de comenzar, te recomendamos revisar la descripción general de Platform para comprender el panorama general de Google Cloud. También te recomendamos que leas la descripción general del producto Secret Manager.

Introducción

La rotación periódica ayuda a lograr lo siguiente:

  • Limitar el impacto en el caso de un secreto filtrado.
  • Asegúrate de que las personas que ya no requieran acceso a un secreto no puedan usar los valores de secretos anteriores.
  • Ejecutar de forma continua el flujo de rotación para reducir la probabilidad de una interrupción en caso de una rotación de emergencia

Secret Manager tiene un concepto de Secretos, Versiones de Secrets y Programas de rotación, que proporcionan una base para compilar cargas de trabajo que admitan secretos rotados.

En este tema, se proporcionan recomendaciones para rotar los secretos almacenados en Secret Manager. En las siguientes secciones, se exploran los beneficios y desventajas:

Vincula a una versión del Secret

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

Se puede hacer referencia a la última versión del secreto que se agregó a un secreto 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 dar lugar a una interrupción en todo el servicio. Los métodos alternativos para la vinculación a una versión del secreto se describen en las siguientes situaciones.

Lanzamientos graduales

Los lanzamientos graduales son un principio rector para las siguientes situaciones. Si eliges un lanzamiento secreto más lento, hay menos riesgo de fallas, pero también un tiempo de recuperación más lento. Algunos Secrets pueden no ser válidos en sistemas externos (como APIs o bases de datos que rastrean valores de Secret válidos) que pueden o no estar 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 potente debería poder detectar automáticamente la falla (por ejemplo, las tasas de errores de HTTP) y la reversión para usar la versión más antigua del secreto (a través de una implementación de configuración anterior).

El lanzamiento de la versión nueva del secreto depende de cómo estos estén vinculados a tu aplicación.

Enfoque 1: Resuelve los problemas durante un proceso de lanzamiento existente

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 del recurso de la versión completa del secreto y, luego, implementarlo con la aplicación como una marca o en un archivo de configuración. Recomendamos resolver el nombre de la versión del secreto en el momento de la rotación, almacenar el nombre del recurso en algún lugar duradero (por ejemplo, confirmar en Git) y extraer el nombre de la versión a la configuración de implementación durante el envío para evitar implementaciones bloqueadas.

Cuando se inicie la aplicación, llama a Secret Manager con el nombre de versión específico del secreto para acceder a su valor.

Este enfoque tiene los siguientes beneficios:

  • Tu aplicación usa la misma versión del secreto en todos los reinicios, lo que aumenta la previsibilidad y reduce la complejidad operativa.
  • Los procesos de administración de cambios existentes para lanzamientos y reversiones se pueden volver a usar para la rotación de secretos y la implementación de versiones de secretos.
  • El valor se puede lanzar de forma gradual, lo que reduce el impacto de la implementación de valores incorrectos.

Enfoque 2: Resolver el problema cuando se inicie la aplicación

Recuperar la carga útil más reciente del secreto en el inicio de la aplicación y seguir usándolo mientras dure la aplicación

La ventaja de este enfoque es que no requiere modificar la canalización de CI/CD para resolver las versiones de los secretos, pero si se lanza un secreto incorrecto, la aplicación no se iniciará cuando las instancias se reinicien o el servicio se escale verticalmente y puede generar una interrupción del servicio.

Enfoque 3: Resolver continuamente

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

Con este enfoque, se genera una interrupción inmediata en todo el servicio, ya que no hay una adopción gradual del valor del secreto nuevo.

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 de forma periódica. Los pasos generales se describen en la siguiente sección con Cloud Run como un entorno de procesamiento de muestra.

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 rotarlo. Consulta la guía Notificaciones de eventos para configurar temas en tus secretos.

Iniciar un Cloud Run para crear una nueva versión del 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 nuevo en el sistema externo (por ejemplo, base de datos o proveedor de 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 un SecretVersion nuevo en Secret Manager. Esto también actualizará el alias latest para que apunte al secreto recién creado.

Reintentos y simultaneidad

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

Recomendamos configurar los reintentos en Pub/Sub para que las rotaciones interrumpidas o con errores se puedan volver a ejecutar. Además, configura la simultaneidad máxima y la cantidad máxima de instancias en el 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 de reentrante, puede resultarte ú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 Secrets para guardar el estado durante la rotación. Agrega una etiqueta al secreto para hacer un seguimiento de la cantidad de la última versión agregada de forma correcta durante el flujo de trabajo de rotación (es decir, ROTATING_TO_NEW_VERSION_NUMBER=3). Una vez que se complete la rotación, quita la etiqueta de seguimiento de rotación.
  • Usa ETag para verificar que otros procesos no modifiquen simultáneamente el secreto durante el flujo de trabajo de rotación. Obtén más información sobre las ETag de versiones secretas y de secretos.

Permisos de Identity and Access Management

Tu proceso de rotación requerirá el permiso secretmanager.versions.add para agregar una nueva versión del secreto y es posible que se requiera que secretmanager.versions.access lea la versión anterior.

La cuenta de servicio predeterminada de Cloud Run tiene la función de editor, que incluye permiso para agregar versiones de secretos, pero no para acceder a ellos. Para seguir el principio de privilegio mínimo, te recomendamos que NO uses la cuenta de servicio predeterminada. En su lugar, configura una cuenta de servicio separada para el 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

Implementa la nueva SecretVersion en las cargas de trabajo

Ahora que se registró un SecretVersion válido nuevo en el sistema externo y se almacenó en Secret Manager, impleméntalo en tu aplicación. Este lanzamiento varía según tu enfoque de vinculación de secretos (consulta la sección Vincula a una versión del secreto) y, por lo general, no requiere intervención manual.

Limpia versiones anteriores de los secretos

Una vez que todas las aplicaciones se roten de la versión del secreto anterior, se puede limpiar de manera segura. El proceso de limpieza dependerá del tipo de secreto, pero, en general, tiene las siguientes características:

  1. Asegúrate de que la nueva versión del secreto se haya lanzado por completo en todas las aplicaciones.
  2. Inhabilita la versión del secreto anterior 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 interrumpe a un consumidor).
  3. Quita o cancela 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?