Ce guide présente quelques bonnes pratiques lors de l'utilisation de Secret Manager. Ce guide n'est pas une liste exhaustive de recommandations. Nous vous recommandons de consulter la présentation de la plate-forme afin de comprendre le paysage Google Cloud et Présentation de Secret Manager avant de lire ce guide.
Contrôle des accès
L'accès à l'API Secret Manager est protégé par IAM. Respectez le principe du moindre privilège lorsque vous accordez des autorisations aux secrets.
- Limitez la propriété de l'organisation à un compte super-administrateur sécurisé.
- Segmentez les applications et les environnements (préproduction/production) en projets distincts, comme décrit dans Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud. Cela permet d'isoler avec une liaison IAM au niveau du projet et garantit les quotas sont appliqués de manière indépendante.
- Choisissez un rôle organisé avec les autorisations minimales nécessaires ou créez un rôle personnalisé si nécessaire.
- Lorsque les secrets de nombreux services se trouvent dans un même projet, utilisez les Liaisons IAM au niveau secret ou les Conditions IAM pour limiter l'accès au sous-ensemble de secrets nécessaire.
- L'outil de recommandation IAM peut vous aider à identifier les liaisons IAM possédant trop de privilèges.
Ces identifiants sont requis pour s'authentifier auprès de l'API Secret Manager. Les bibliothèques clientes utilisent toutes une stratégie similaire pour rechercher les identifiants appelés Identifiants par défaut de l'application.
- Lorsque vous développez en local, utilisez
gcloud auth application-default login. Cela crée un fichier avec des identifiants qui sont automatiquement récupérés par les bibliothèques clientes. - Sur Compute Engine et d'autres plates-formes de calcul Google Cloud telles que fonctions Cloud Run, les bibliothèques clientes obtiennent des identifiants via la serveur de métadonnées d'instance.
- Sur GKE, Workload Identity fournit également des identifiants via un service de métadonnées.
- Sur d'autres plates-formes telles qu'Amazon Web Services ou Microsoft Azure, envisagez de configurer la fédération d'identité de charge de travail qui utilise les mécanismes d'identité existants pour l'authentification auprès des API Google Cloud.
Toutes ces méthodes sont préférables à l'exportation des identifiants de compte de service, car elles ne nécessitent pas de stocker ni d'accéder en toute sécurité à un secret supplémentaire en dehors de l'API Secret Manager.
Bonnes pratiques de codage
Transmettre des secrets à votre application via le système de fichiers ou l'environnement est courante, mais doit être évitée dans la mesure du possible pour les raisons suivantes:
- Lorsqu'un secret est accessible sur le système de fichiers, les failles des applications telles que les attaques de balayage de répertoire peuvent devenir plus graves, car le pirate informatique peut obtenir la possibilité de lire le matériel du secret.
- Lorsqu'un secret est utilisé via des variables d'environnement, des erreurs de configuration telles que l'activation des points de terminaison de débogage ou l'inclusion de dépendances qui consignent les détails de l'environnement peuvent entraîner des fuites de secrets.
- Lorsque vous synchronisez un matériel de secret avec un autre magasin de données (comme Kubernetes Secrets), prenez en compte les contrôles d'accès de ce magasin de données, par exemple :
- Le datastore étend-il l'accès au secret ?
- Est-il possible de vérifier l'accès au secret ?
- Le datastore respecte-t-il les exigences de chiffrement et de régionalisation des données au repos ?
Nous vous recommandons d'utiliser directement l'API Secret Manager (en utilisant l'une des bibliothèques clientes fournies ou en suivant la documentation REST ou GRPC).
Toutefois, pour certaines intégrations de produits telles que les intégrations sans serveur, vous pouvez transmettre les secrets via le système de fichiers ou via les variables d'environnement. Pour en savoir plus, consultez la page Utiliser Secret Manager avec d'autres produits.
Administration
Choisissez la règle de réplication automatique lors de la création de secrets, sauf si votre charge de travail impose des exigences d'emplacement spécifiques (appliquées à l'aide de la contrainte constraints/gcp.resourceLocations).
Référencez les secrets par leur numéro de version plutôt que d'utiliser le dernier alias. Déployez les mises à jour vers les numéros de version à l'aide de vos processus de publication existants. En règle générale, cela signifie que vous devez configurer votre application avec une version de secret spécifique qui est lue au démarrage. Bien que l'utilisation du dernier alias puisse être pratique, en cas de problème avec la nouvelle version du secret, votre charge de travail peut ne pas être en mesure de l'utiliser. En épinglant un numéro de version, la configuration peut être validée et annulée et un rollback peut être effectué à l'aide de vos processus de version existants.
Désactivez les versions des secrets avant de les détruire ou de les supprimer. Cela permet d'éviter les pannes en plaçant un secret dans un état qui ressemble à « détruire », mais qui est réversible. En d'autres termes, vous pouvez désactiver cette fonctionnalité et patienter une semaine afin d'être sûr que le problème dépendances avant de supprimer définitivement des données.
Ne définissez pas de délai d'expiration sur les secrets de production, sauf si vous êtes certain qu'il doit être supprimé de manière irréversible. La fonctionnalité d'expiration est particulièrement adaptée au nettoyage automatisé des environnements temporaires. Considérez les conditions IAM basées sur le temps comme alternative à l'expiration des secrets.
Effectuez régulièrement une rotation des secrets pour :
- Limiter l'impact en cas de fuite d'un secret.
- S'assurer que les personnes qui n'ont plus besoin d'accéder à un secret ne peuvent pas continuer à utiliser un secret auquel elles ont eu accès dans le passé.
- Exercer en continu le flux de rotation pour réduire la probabilité d'une panne.
Surveillez les secrets dans votre organisation à l'aide de l'inventaire des éléments cloud pour...
- Identifier les secrets au sein de votre organisation.
- Identifier la non-conformité aux exigences de l'organisation telles que la rotation, la configuration du chiffrement et l'emplacement.
Activez les journaux d'accès aux données pour obtenir et analyser les informations de requête AccessSecretVersion. Activez cette fonctionnalité au niveau du dossier ou de l'organisation pour appliquer la journalisation sans avoir à la configurer sur chaque secret ou projet.
En plus des contrôles IAM, vous pouvez limiter l'accès à l'API Secret Manager à l'aide de contrôles basés sur le réseau en configurant un périmètre VPC Service Controls pour votre organisation.
La règle d'administration constraints/iam.allowedPolicyMemberDomains peut être utilisée pour limiter les identités pouvant être ajoutées aux stratégies IAM pour les secrets.
Estimez votre utilisation maximale de secret (en considérant un "problème de réveil superflu") de requêtes en raison de déploiements simultanés d'applications ou de l'autoscaling de votre service) et assurez-vous que votre projet dispose de quota suffisant pour gérer un tel événement. Si vous avez besoin d'augmenter votre quota, demandez une augmentation.