La rotation des secrets consiste à mettre à jour ou à remplacer périodiquement des informations sensibles (secrets) telles que des mots de passe, des clés API ou des clés de chiffrement. La rotation des secrets permet de réduire le risque d'accès non autorisé ou de mauvaise utilisation des secrets, en particulier s'ils ont été compromis ou divulgués.
La rotation périodique présente les avantages suivants:
-
Limite l'impact en cas de fuite d'un secret.
-
S'assure que les personnes qui n'ont plus besoin d'accéder à un secret ne peuvent pas utiliser d'anciennes valeurs de secret.
-
Réduit le risque de perturbation du service si vous devez effectuer une rotation urgente des secrets.
Secret Manager comprend les concepts de secrets, de versions de secrets et de calendriers de rotation, qui constituent la base de la création de charges de travail compatibles avec les secrets alternés.
Cette page fournit des recommandations pour la rotation des secrets stockés dans Secret Manager. Vous allez apprendre à effectuer les opérations suivantes:
Avant de commencer, nous vous recommandons de lire la présentation de la plate-forme pour comprendre l'environnement général de Google Cloud. Nous vous recommandons également de lire la présentation du produit Secret Manager.
Lier une version de secret à votre application
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 :
-
Récupérez ou créez un secret dans le système externe (base de données, fournisseur d'API, etc.).
Assurez-vous que cela n'invalide pas les secrets existants afin que les charges de travail existantes ne soient pas affectées.
-
Mettez à jour Secret Manager avec le nouveau secret.
Créez une version de secret dans Secret Manager. Cette opération mettra également à jour l'alias
latestpour 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 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 l'autorisation secretmanager.versions.access pour lire la version précédente du secret.
Votre processus de rotation nécessite l'autorisation secretmanager.versions.add pour ajouter une nouvelle version de secret et peut nécessiter l'autorisation secretmanager.versions.access pour lire 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 la nouvelle version de secret dans les charges de travail
Maintenant qu'une nouvelle version de secret valide a été enregistrée auprès du système externe et stockée dans Secret Manager, déployez-la dans votre application. Ce déploiement varie en fonction de la méthode que vous adoptez pour la liaison de secrets 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:
-
Assurez-vous que la nouvelle version de secret a été entièrement déployée dans toutes les applications.
-
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).
-
Supprimez ou annulez l'enregistrement de l'ancienne version du secret du système externe.
-
Supprimez l'ancienne version de secret dans Secret Manager.