À propos des calendriers de rotation

Cet article présente le concept de rotation des secrets. Avant de commencer, nous vous recommandons de consulter la présentation de la plate-forme pour comprendre l'environnement global de Google Cloud. Nous vous recommandons également de lire la présentation de Secret Manager.

Introduction

La rotation périodique permet de :

  • Limiter l'impact en cas de fuite d'un secret.
  • Assurez-vous que les personnes qui n'ont plus besoin d'accéder à un secret ne peuvent pas utiliser les anciennes valeurs de secrets.
  • Maintenir le flux de rotation en continu pour réduire les risques de panne en cas de besoin de rotation d'urgence.

Secret Manager comprend les concepts de Secrets, Versions des secrets et Calendriers de rotation, qui constituent la base de la création de charges de travail compatibles avec les secrets alternés.

Cet article fournit des recommandations concernant la rotation des secrets stockés dans Secret Manager. Les sections suivantes présentent les avantages et les compromis pour :

Liaison à une version de secret

Un secret dans Secret Manager peut avoir plusieurs versions de secrets. Les versions des secrets contiennent la charge utile immuable (la chaîne d'octets du secret réelle) et sont classées et numérotées. Pour effectuer la rotation d'un secret, ajoutez une nouvelle version de secret à un secret existant.

La version la plus récente d'un secret peut être référencée à l'aide de l'alias latest. L'alias latest, s'il est pratique pour le développement, peut poser problème pour certaines charges de travail de production, car une valeur incorrecte peut être immédiatement déployée et entraîner une interruption de service. D'autres méthodes de liaison à une version de secret sont décrites dans les scénarios suivants.

Déploiements progressifs

Les déploiements progressifs constituent un principe directeur pour les scénarios suivants. En choisissant un déploiement secret plus lent, vous réduisez les risques de faille, mais le temps de récupération est également plus long. Certains secrets peuvent être invalidés dans des systèmes externes (tels que des API ou des bases de données qui suivent des valeurs de secret valides) dont vous avez ou non le contrôle et la récupération dans ce cas exige un déploiement.

Il est possible qu'un secret incorrect soit déployé lors d'une rotation manuelle ou automatique. Un workflow de rotation solide doit pouvoir détecter automatiquement la faille (par exemple, les taux d'erreur HTTP) et effectuer un rollback pour utiliser l'ancienne version du secret (via un déploiement de configuration précédent).

Le déploiement de la nouvelle version de secrets dépend de la manière dont les secrets sont liés à votre application.

Approche 1 : Résolution lors d'un processus de publication existant

Résolvez et associez votre version de secret avec la version de votre application. Pour la plupart des déploiements, cela implique de résoudre la dernière version de secret dans le nom complet de la ressource de version de secret et de la déployer avec l'application sous forme d'option ou dans un fichier de configuration. Nous vous recommandons de résoudre le nom de la version de secret au moment de la rotation, de stocker le nom de la ressource dans un environnement durable (par exemple, commit dans Git) et d'extraire le nom de la version dans la configuration de déploiement lors du transfert pour éviter le blocage de déploiements.

Au démarrage de l'application, appelez Secret Manager avec le nom spécifique de la version du secret pour accéder à la valeur du secret.

Cette approche présente les avantages suivants :

  • Votre application utilise la même version de secret lors des redémarrages, ce qui améliore la prévisibilité et réduit la complexité opérationnelle.
  • Les processus existants de gestion du changement pour les déploiements et les rollbacks peuvent être réutilisés pour la rotation des secrets et le déploiement de la version d'un secret.
  • La valeur peut être déployée progressivement, ce qui réduit l'impact du déploiement de valeurs incorrectes.

Approche 2 : Résolution au démarrage de l'application

Récupérez la dernière charge utile du secret au démarrage de l'application et continuez à utiliser le secret pendant toute la durée de l'application.

L'avantage de cette approche est qu'elle ne nécessite pas de modifier le pipeline CI/CD pour résoudre les versions de secrets. Toutefois, si un secret incorrect est déployé, l'application ne démarre pas au redémarrage des instances ou le service augmente sa capacité et cela peut entraîner un risque d'indisponibilité du service.

Méthode 3 : résoudre continuellement

Interrogez la dernière version du secret en continu dans l'application et utilisez immédiatement la nouvelle valeur du secret.

Cette approche risque d'entraîner une interruption immédiate à l'échelle du service, car la nouvelle valeur du secret n'est pas progressivement adoptée.

Effectuer une rotation de votre secret

Si votre secret peut être mis à jour de manière dynamique (par exemple, si le système externe validant le secret fournit une API d'administration), nous vous recommandons de configurer une tâche de rotation qui s'exécute régulièrement. Les étapes générales sont décrites dans la section suivante avec Cloud Run comme exemple d'environnement de calcul.

Configurer un calendrier de rotation sur votre secret

Définissez un calendrier de rotation pour votre secret. Les sujets Pub/Sub doivent être configurés sur le secret pour recevoir des notifications au moment de la rotation du secret. Consultez le guide Notifications d'événements pour configurer des sujets sur vos secrets.

Lancer Cloud Run pour créer une nouvelle version de secret

Créez et configurez un service Cloud Run pour recevoir des notifications de rotation et exécuter des étapes de rotation :

  1. Obtenez ou créez un secret dans le système externe (par exemple, une base de données ou un fournisseur d'API).

    Assurez-vous que cela n'invalide pas les secrets existants afin que les charges de travail existantes ne soient pas affectées.

  2. Mettez à jour Secret Manager avec le nouveau secret.

    Créez un objet SecretVersion dans Secret Manager. Cette opération mettra également à jour l'alias latest pour qu'il pointe vers le secret nouvellement créé.

Tentatives et simultanéité

Étant donné que votre processus de rotation peut être interrompu à tout moment, votre service Cloud Run doit pouvoir le redémarrer à partir de l'emplacement où il s'était arrêté (il doit être réentrant).

Nous vous recommandons de configurer les nouvelles tentatives dans Pub/Sub afin de pouvoir réexécuter des rotations ayant échoué ou interrompues. Configurez également la simultanéité maximale et le nombre maximal d'instances sur votre service Cloud Run de façon à réduire la probabilité d'interférences d'exécutions de rotation simultanées.

Pour créer une fonction de rotation réentrante, il peut être utile d'enregistrer l'état afin de permettre le redémarrage du processus de rotation. Deux fonctionnalités de Secret Manager peuvent vous y aider :

  • Utilisez des libellés sur les secrets pour enregistrer l'état lors de la rotation. Ajoutez un libellé au secret pour suivre le nombre de la dernière version ajoutée avec succès pendant le workflow de rotation (par exemple, ROTATING_TO_NEW_VERSION_NUMBER=3). Une fois la rotation terminée, supprimez le libellé de suivi de la rotation.
  • Utilisez des ETags pour vérifier que d'autres processus ne modifient pas simultanément le secret pendant le workflow de rotation. En savoir plus sur les ETags des secrets et des versions de secrets.

Autorisations Identity and Access Management

Votre processus de rotation nécessite l'autorisation secretmanager.versions.add pour ajouter une nouvelle version de secret et peut nécessiter la lecture par secretmanager.versions.access de la version précédente du secret.

Le compte de service Cloud Run par défaut dispose du rôle Éditeur, qui inclut l'autorisation d'ajouter des versions de secret, mais pas d'y accéder. Pour respecter le principe du moindre privilège, nous vous recommandons de NE PAS utiliser le compte de service par défaut. À la place, configurez un compte de service distinct pour votre service Cloud Run avec les rôles Secret Manager accordés si nécessaire (il peut s'agir d'un ou plusieurs des rôles suivants) :

  • roles/secretmanager.secretVersionAdder
  • roles/secretmanager.secretVersionManager
  • roles/secretmanager.secretAdmin
  • roles/secretmanager.secretAccessor

Déployer le nouveau SecretVersion sur les charges de travail

Maintenant qu'un nouveau SecretVersion valide a été enregistré auprès du système externe et stocké dans Secret Manager, déployez-le dans votre application. Ce déploiement varie en fonction de la méthode que vous adoptez pour la liaison de secrets (consultez la section Lier une version de secret) et ne nécessite généralement pas d'intervention manuelle.

Nettoyer les anciennes versions des secrets

Une fois que toutes les applications sont désactivées de l'ancienne version du secret, elles peuvent être nettoyées en toute sécurité. Le processus de nettoyage dépend du type de secret, mais de manière générale :

  1. Assurez-vous que la nouvelle version de secret a été entièrement déployée dans toutes les applications.
  2. Désactivez l'ancienne version de secret dans Secret Manager et vérifiez que les applications ne se mettent pas en échec (attendez un délai raisonnable pour permettre à un humain d'intervenir si la désactivation bloque un consommateur).
  3. Supprimez ou annulez l'enregistrement de l'ancienne version du secret du système externe.
  4. Supprimez l'ancienne version de secret dans Secret Manager.

Étapes suivantes