Pourquoi les secrets ne doivent jamais rester dans Terraform
Laisser un secret en dur dans un fichier Terraform ou dans l'état du projet est une faille critique de sécurité. Dès qu'un commit contient une clé AWS, un token d'API ou un mot de passe de base de données, votre infrastructure devient vulnérable : n'importe quel contributeur du dépôt git, tout auditeur externe ou même un attaquant qui compromettrait votre système de contrôle de version accède immédiatement à vos ressources cloud. L'état Terraform (.tfstate) est encore plus sensible car il stocke non seulement la configuration déclarée, mais aussi les données runtime, y compris les secrets en clair après qu'ils aient été injectés dans les ressources (mots de passe RDS générés, token de base de données, clés de chiffrement). Si cet état est stocké localement sans chiffrement ou commit accidentellement sur git, ou si l'accès au bucket S3 distant qui le contient n'est pas restreint, chaque secret de votre production peut être exfiltré en quelques secondes. Terraform ne chiffre pas les variables sensibles marquées avec « sensitive = true » : ce marqueur empêche seulement Terraform d'afficher la valeur brute dans les logs et la sortie d'une terraform apply, il ne protège pas le stockage réel de l'état. C'est pourquoi les équipes qui adoptent Terraform sérieusement établissent immédiatement une distinction claire entre configuration non sensible (que git peut stocker) et données sensibles (que seul un gestionnaire de secrets dédié connaît et fournit à Terraform au moment du déploiement).
AWS Secrets Manager et Parameter Store pour centraliser les secrets
AWS propose deux services natifs pour stocker les secrets de manière sécurisée et les rendre accessibles à Terraform lors du déploiement : AWS Secrets Manager et AWS Systems Manager Parameter Store. AWS Secrets Manager est conçu pour les secrets critiques et de longue durée, comme les identifiants de base de données, les clés API externes ou les certificats SSL. Chaque secret stocké est chiffré avec AWS KMS par défaut, et l'accès est contrôlé par des politiques IAM granulaires : seul un rôle ou utilisateur autorisé peut récupérer le secret, et chaque accès est journalisé dans CloudTrail. AWS Secrets Manager supporte aussi la rotation automatique des secrets : vous pouvez configurer une fonction Lambda qui renouvelle votre mot de passe RDS selon un calendrier prédéfini, sans intervention manuelle. Parameter Store est plus léger et gratuit pour les paramètres standard (il facture seulement les paramètres avancés, qui offrent des fonctionnalités comme le versionning ou les politiques d'expiration). Il convient bien pour des valeurs moins sensibles comme des URLs d'API, des tokens de déploiement, ou des identifiants externes. Les deux services intègrent AWS KMS pour le chiffrement au repos, et leurs politiques IAM garantissent que Terraform ne peut récupérer que les secrets dont le rôle d'exécution (role AssumeRole du compte AWS) a la permission explicite. Dans Terraform, vous utilisez la datasource « aws_secretsmanager_secret_version » pour Secrets Manager ou « aws_ssm_parameter » pour Parameter Store, ce qui signifie que le secret est résolu seulement lors de terraform apply, jamais stocké en dur dans vos fichiers de configuration. La pratique courante est de stocker en Secrets Manager les secrets les plus critiques (identifiants de base de données métier, clés de production), et en Parameter Store les valeurs de configuration qui nécessitent du contrôle d'accès mais sont moins critiques.
Utiliser les datasources Terraform pour récupérer les secrets à l'exécution
Dans Terraform, vous ne déclarez jamais le secret lui-même dans la configuration. À la place, vous créez une datasource qui interroge Secrets Manager ou Parameter Store au moment de l'exécution. Pour AWS Secrets Manager, la syntaxe est simple : vous définissez une ressource data « aws_secretsmanager_secret_version » en spécifiant l'ARN ou le nom du secret, et Terraform récupère la valeur actuelle seulement lors de terraform apply. Exemple concret : si votre secret s'appelle « prod/rds/password » dans Secrets Manager, vous écrivez data « aws_secretsmanager_secret_version » « rds_password » avec secret_id = « prod/rds/password », puis vous référencez le secret via data.aws_secretsmanager_secret_version.rds_password.secret_string en tant que mot de passe pour votre ressource RDS. Terraform ne l'affichera jamais en clair dans les logs, et l'état contiendra une référence chiffrée. Pour Parameter Store, le pattern est similaire avec data « aws_ssm_parameter » : vous interrogez le paramètre par chemin, et Terraform le résout à l'exécution. Une pratique importante : combinez cette datasource avec la variable « sensitive = true » sur la ressource qui consomme le secret (par exemple, la ressource aws_db_instance pour RDS). Cela signifie que même si Terraform a techniquement accès au secret en mémoire lors du plan ou de l'apply, il ne l'affichera pas dans la sortie console ou dans les logs, réduisant ainsi le risque d'exposition accidentelle. Vous pouvez aussi utiliser aws_secretsmanager_secret pour créer des secrets directement via Terraform, mais le vrai secret (sa valeur) doit toujours être injecté de manière externe, jamais codée en dur dans le plan.
Sécuriser l'état Terraform (tfstate) et les backends distants
L'état Terraform est un fichier JSON qui décrit l'état actuel de votre infrastructure et contient des données sensibles en clair, même si vous utilisez des datasources pour récupérer les secrets. Lorsque vous exécutez terraform apply et que Terraform crée une ressource (par exemple une instance RDS), il stocke la valeur du mot de passe résolue dans l'état local (.tfstate) ou dans le backend distant (par exemple S3). Beaucoup d'équipes le découvrent trop tard en grep-ant accidentellement leur état et en trouvant les secrets exposés. La première défense est de ne jamais commiter le fichier .tfstate local dans git : ajoutez toujours .tfstate et .terraform.lock.hcl dans .gitignore. La deuxième, et plus importante, est d'utiliser un backend distant sécurisé (S3, Terraform Cloud, ou autre) avec chiffrement et contrôle d'accès strict. Si vous utilisez S3 pour stocker l'état, configurez le bucket avec le versioning activé, la journalisation d'accès CloudTrail, et une politique de bucket très restrictive qui autorise seulement les rôles IAM d'exécution (par exemple le rôle de votre pipeline CI/CD) à lire et écrire l'état. Activez également le server-side encryption (SSE-S3 ou mieux encore SSE-KMS avec une clé KMS gérée) pour chiffrer l'état au repos, et force le transport TLS (aws:SecureTransport) pour chiffrer le secret en transit. Avec Terraform Cloud ou Terraform Enterprise (la version SaaS ou auto-hébergée de HashiCorp), l'état est automatiquement chiffré au repos et en transit, et HashiCorp gère l'infrastructure sous-jacente, ce qui peut simplifier la conformité. Quelle que soit votre approche, rappelez-vous que l'état est un secret : traitez-le avec autant de soin que vos clés AWS root.
Variables Terraform sensibles et recommandations de gestion
Terraform supporte une variable option « sensitive = true » qui empêche la valeur d'être affichée en clair dans la console lors d'une terraform plan ou apply. Cependant, cela n'affecte que l'affichage, pas le stockage : la valeur reste en clair dans l'état. La recommandation est donc de combiner le marqueur sensitive avec une source de secret externe (Secrets Manager, Parameter Store, ou même des variables d'environnement injectées par votre pipeline). Une approche commune dans les équipes DevOps : les secrets critiques (clés AWS, tokens de production) viennent de Secrets Manager via datasource, tandis que les variables de configuration moins sensibles (URLs d'API internes, noms de ressources) viennent de fichiers .tfvars ou de variables d'environnement TF_VAR_*. Les fichiers .tfvars eux-mêmes doivent être gitignore ou stockés en dehors du dépôt, dans un système sécurisé (par exemple, un bucket S3 chiffré accessible seulement par le pipeline CI/CD). Si vous gérez plusieurs environnements (dev, staging, prod), il est tentant de créer des fichiers .tfvars.dev, .tfvars.prod, etc., et de les versionner tous ensemble. C'est une anti-pattern : les données sensibles de prod ne devraient jamais être versionnées avec le code source, même chiffrées, car cela augmente la surface d'exposition. Préférez une approche où les variables propres à chaque environnement sont injectées au runtime par votre système CI/CD ou par des webhooks vers votre gestionnaire de secrets. Avec Terraform Cloud, vous pouvez marquer des variables comme sensibles dans l'interface web, et elles ne seront jamais affichées, même par l'équipe qui les a créées. C'est une excellente pratique pour externaliser complètement la gestion des secrets hors du code source.
Audit et rotation des secrets dans une infrastructure Terraform
Une fois que vous avez centralisé vos secrets dans AWS Secrets Manager ou Parameter Store, les auditer et les renouveler devient systématique. AWS CloudTrail enregistre chaque appel aux API Secrets Manager (GetSecretValue, UpdateSecret, etc.), ce qui signifie que vous pouvez tracer qui a accédé à quel secret, quand et depuis quel rôle IAM. Configurez CloudTrail pour envoyer ses journaux vers CloudWatch Logs ou S3 afin de les analyser avec des outils comme Amazon Athena ou d'émettre des alertes si quelqu'un tente un accès non autorisé. La rotation des secrets est une étape critique que beaucoup d'équipes ignorent : un secret stocké indéfiniment devient une bombe à retardement si une personne avec un accès passé le récupère hors canal, ou si une clé AWS est accidentellement exposée dans un ancien dépôt. AWS Secrets Manager supporte la rotation automatique via des fonctions Lambda : vous pouvez configurer une politique qui dit « tous les 30 jours, générer un nouveau mot de passe RDS et mettre à jour la ressource », sans action manuelle. Pour les secrets générés par vous (comme des tokens API ou des clés API externes), Secrets Manager ne peut pas les rotationner automatiquement (car il n'a pas accès au système externe pour regénérer la clé), mais vous pouvez mettre en place une Lambda personnalisée qui, lors de la rotation, appelle l'API du système externe pour émettre une nouvelle clé, la stocke dans Secrets Manager, et notifie votre infrastructure de mettre à jour ses configurations. Dans Terraform, vous pouvez déclencher des mises à jour de ressources lorsqu'un secret change en utilisant la meta-argument « triggers » : si la version du secret change, vous forcez un redéploiement. Cela garantit que votre infrastructure utilise toujours la dernière version d'un secret en rotation.
Intégration des secrets Terraform dans une pipeline CI/CD sécurisée
Aucune sécurisation des secrets Terraform n'est complète sans une pipeline CI/CD qui respecte les mêmes principes. Dans une approche moderne, lorsqu'un ingénieur pousse un changement Terraform dans git, la pipeline clone le dépôt, fait un terraform plan pour montrer les changements proposés, et attend une approbation avant d'appliquer les changements. À chaque étape, aucun secret ne doit être stocké localement ou loggé. Utilisez des outils comme GitHub Actions, GitLab CI, ou Jenkins avec des plugins AWS qui s'authentifient au compte AWS via des rôles IAM temporaires (OIDC - OpenID Connect) plutôt que des clés d'accès longue durée. L'authentification par OIDC signifie que votre pipeline se connecte au compte AWS sans jamais stocker de clés d'accès : le token OIDC généré par GitHub, GitLab ou Jenkins est échangé contre un token de sécurité AWS temporaire et limité en permissions. Configurez la pipeline pour récupérer les secrets de Secrets Manager ou Parameter Store seulement au moment de terraform apply, via le rôle IAM de la pipeline elle-même. Ne versionnez jamais de fichiers .tfvars contenant des secrets, et n'affichez jamais les variables sensibles dans les logs : utilisez la sortie maskée des logs (masking des secrets listés dans le pipeline) fournie par la plupart des outils CI/CD. Pour les environnements multi-comptes (dev dans un compte AWS, prod dans un autre), utilisez la délégation de rôle (assume-role) pour que la pipeline s'authentifie d'abord au compte principal, puis assume un rôle dans le compte cible pour appliquer Terraform. Cette couche supplémentaire isole les secrets de production des secrets de développement et limite l'impact d'une compromission de la pipeline. Documentez et auditez qui a accès à la pipeline, quels rôles elle assume, et comment elle accède aux secrets, afin que tout audit de conformité (PCI-DSS, ISO 27001, SOC 2) puisse vérifier que les pratiques de sécurité des secrets sont respectées de bout en bout.