Pourquoi la gestion des secrets doit être strictement séparée de votre code et de vos configurations
Même sur des équipes réduites, une première tentation surgit régulièrement : laisser des identifiants en clair dans les variables d'environnement fichées dans le code ou dans un fichier .env commité. Cette pratique crée un risque d'exposition massive lors d'une fuite de dépôt, d'une capture d'écran, ou d'un accès historique au contrôle de version. Elle rend aussi impossible l'audit : qui a eu accès à quelle clé, à quel moment ? Les entreprises qui ont suivi cette route finissent par devenir des cibles faciles pour les attaquants, qui n'ont qu'à scraper les dépôts publics ou privés pour trouver des tokens AWS, des clés Stripe, ou des certificats.
Dès que vos pipelines de déploiement s'interconnectent (pull depuis GitHub, push vers ECR, appels à une base de données, notification Slack), chaque étape a besoin d'une identité distincte et d'une justification précise. Si vous accordez à votre pipeline de CI/CD un secret qui donne accès à TOUS les secrets du compte AWS, une faille dans votre outil de CI/CD devient une faille dans tout votre système. La bonne pratique consiste donc à centraliser les secrets dans un service dédié (AWS Secrets Manager ou Systems Manager Parameter Store), à restreindre l'accès via IAM avec le principe du moindre privilège (chaque service ne reçoit que ce qu'il lui faut), et à automatiser l'injection au moment du déploiement sans jamais laisser le secret transiter en clair via des logs ou des artifacts intermédiaires.
Le bénéfice concret : en cas de compromission, vous pouvez révoquer un secret en secondes sans redéployer le code, et vous disposez d'une traçabilité complète des accès. Pour les scale-ups qui grossissent vite, c'est la différence entre une culture de sécurité mature et une infrastructure qui crée des dettes de sécurité qu'on paiera très cher plus tard.
AWS Secrets Manager, Systems Manager Parameter Store, et IAM : comment les trois s'articulent
AWS vous propose plusieurs briques pour gérer les secrets et identités. AWS Secrets Manager est optimisé pour les secrets qui changent régulièrement (identifiants de base de données, clés d'API externes, certificats) : il stocke le secret, offre un versioning, un historique de rotation, et des webhooks pour déclencher des actions (par exemple mettre à jour la base de données) quand un secret a tourné. Systems Manager Parameter Store (également appelé SSM) est plus léger, sans rotation native, mais suffisant pour les identifiants statiques ou les petits secrets, avec un accès granulaire par IAM et une intégration fluide dans CloudFormation et Terraform.
Le choix entre Secrets Manager et Parameter Store dépend de votre charge d'automatisation. Si vous travaillez avec des RDS qui tournent avec un identifiant auto-rotatif, ou si vous gérez des certifications Let's Encrypt qui expirent régulièrement, Secrets Manager justifie son coût (0,40 USD par secret par mois) via sa capacité à orchestrer les changements et notifier les systèmes affectés. Pour les tokens internes ou les API keys simples, Parameter Store suffit et coûte beaucoup moins cher.
La clé d'articulation entre ces trois éléments (Secrets Manager, Parameter Store, IAM) réside dans les politiques IAM. Vous ne donnez jamais à un rôle IAM le droit de lire TOUS les secrets : au lieu de cela, vous créez une politique qui autorise votre pipeline de déploiement (ou votre pod Kubernetes sur EKS) à lire UNIQUEMENT le secret dont il a besoin, identifié par un tag, un chemin, ou un nom ARN spécifique. Par exemple, une tâche ECS qui doit se connecter à une base de données PostgreSQL recevra un rôle IAM qui autorise uniquement l'action secretsmanager:GetSecretValue pour l'ARN exact du secret contenant le mot de passe PostgreSQL. Si un attaquant réussit à prendre le contrôle de cette tâche, il ne pourra pas accéder à d'autres secrets du compte.
Cette architecture en trois couches (stockage centralisé, contrôle d'accès granulaire, injection automatique) est ce qui sépare une gestion de secrets robuste d'une solution bricolée qui sera contournée dès que la pression de livraison monte.
Injection sécurisée des secrets dans vos pipelines de déploiement CI/CD
Une fois vos secrets centralisés dans Secrets Manager ou Parameter Store, le défi suivant est de les injecter au moment du déploiement sans les exposer dans les logs ou les artifacts. Les trois patterns les plus courants sont l'injection en variables d'environnement, l'injection dans les fichiers de configuration, et l'injection directe en tant que secret Docker ou Kubernetes.
Pour un pipeline GitHub Actions ou GitLab CI, le pattern standard est de récupérer le secret depuis Secrets Manager au début du job de déploiement, de le passer en variable d'environnement chiffrée à un script de déploiement (Terraform, CloudFormation, ou script shell), et de le faire injecter UNIQUEMENT à l'étape précise où il est utilisé (par exemple, la connexion à la base de données) sans jamais l'afficher ou le stocker. GitHub Actions offre une couche de masquage automatique (secrets manager masque les valeurs dans les logs), mais cela ne suffit pas : vous devez aussi verrouiller le dépôt pour ne laisser que les pipelines autorisés et les environnements sécurisés accéder à ces variables.
Dans Kubernetes (EKS), l'approche est de créer des Secrets Kubernetes qui tirent leur contenu depuis AWS Secrets Manager via des outils comme ExternalSecrets Operator ou AWS Secrets and Configuration Provider (ASCP). Concrètement, vous définissez un Kubernetes Secret qui dit "va chercher le secret AWS nomé 'prod-db-password' et mets sa valeur ici". Quand un pod démarre, il a accès au secret sans jamais avoir à le demander manuellement. IAM IRSA (IAM Roles for Service Accounts) garantit que seuls les pods autorisés peuvent accéder à ce secret.
Pour ECS (Elastic Container Service), vous passez le secret via le paramètre secrets de la définition de tâche, qui pointe vers Secrets Manager ou Parameter Store et injecte la valeur directement en variable d'environnement à l'intérieur du conteneur, sans qu'elle ne transite par les logs ou artifacts de déploiement. La tâche elle-même a besoin d'un rôle de tâche ECS avec les droits IAM appropriés pour lire le secret.
Le point critique dans tous ces patterns est le suivant : ne jamais écrire le secret dans un artifact intermédiaire (fichier .env, réponse API non chiffrée, fichier de log) dont un tiers autre que votre infrastructure cible pourrait prendre possession. Chaque étape de votre pipeline doit traiter le secret comme une données sensibles (chiffrée en transit, jamais loggée, jamais sauvegardée). Les meilleures équipes ajoutent une audit trail : logs CloudTrail qui enregistrent CHAQUE lecture d'un secret, alertes si le secret est accédé depuis une région inhabituelle ou hors horaires de déploiement prévus.
Gestion des identités pour les services inter-étapes : IAM, OIDC, et OpenID Connect externe
Au-delà des secrets statiques (mots de passe, clés), la gestion des IDENTITÉS dynamiques est tout aussi critique. Quand votre pipeline GitHub Actions doit pousser une image vers ECR, il ne peut pas utiliser une clé d'accès AWS statique, ni partager un secret AWS root entre tous vos dépôts. La solution moderne est OpenID Connect (OIDC) : GitHub Actions, GitLab CI, ou n'importe quel fournisseur d'identité OIDC établit une relation de confiance avec AWS via un rôle IAM fédéré.
Voici comment cela fonctionne en pratique. Vous créez un rôle IAM spécifique (par exemple, GitHubActionsDeployRole) dont la politique d'assomption de rôle accepte les tokens OIDC émis par GitHub pour votre organisation et votre dépôt. Quand votre pipeline GitHub Actions s'exécute, il demande un token OIDC à GitHub, puis le transmet à AWS en demandant l'assomption du rôle. AWS vérifie le token (que seul GitHub peut émettre), vérifie que le dépôt et la branche correspondent à ce qui est autorisé, et accorde au pipeline un ensemble de droits temporaires et limités. Aucune clé d'accès n'est stockée sur GitHub ; l'identité est temporaire et révoquée à la fin du job.
Ce pattern élimine deux sources majeures de fuite : les clés oubliées dans les logs GitHub et les clés AWS statiques sauvegardées hors du chiffrement. Pour les équipes qui utilisent plusieurs fournisseurs CI/CD (GitHub Actions pour le code, ArgoCD pour le déploiement, Jenkins sur premise pour des builds spécialisés), chacun peut avoir son propre rôle IAM fédéré avec des droits distincts. Un rôle pour GitHub Actions ne permet de déployer que sur les environnements de staging, un rôle pour ArgoCD en production dispose de droits supplémentaires seulement si déployé depuis un cluster Kubernetes sécurisé, etc.
Pour aller plus loin, certaines équipes mettent en place un service d'émission de credentials temporaires interne (par exemple, HashiCorp Vault), qui centralise encore davantage : une seule source de vérité pour tous les secrets et identités, rotations coordonnées, et révocation en un seul endroit. Mais pour la majorité des scale-ups, OIDC + IAM fédéré avec AWS + restriction par branche et environnement offre un très bon rapport sécurité/complexité.
Audit, rotation et révocation : comment vous savez que vos secrets sont vraiment en sécurité
Une gestion de secrets centralisée n'est sécurisée que si vous surveillez son utilisation. AWS CloudTrail enregistre chaque appel à Secrets Manager ou Parameter Store : qui a lu quel secret, quand, depuis quelle IP, via quel rôle IAM. Vous pouvez configurer des alertes CloudWatch pour signaler les accès anormaux (lecture depuis une région inhabituelle, reading d'un secret non utilisé habituellement, accès hors des plages horaires de déploiement). Pour les équipes sensibles à la conformité (GDPR, SOC 2, ISO 27001), ces logs sont obligatoires : ils prouvent que vous avez un contrôle d'accès effectif.
La rotation des secrets est le second pilier de la surveillance. Secrets Manager peut piloter une rotation automatique : vous configurez une Lambda qui change le mot de passe dans la base de données et met à jour le secret dans Secrets Manager, en parallèle elle-même. Pour les secrets plus simples qui ne changent jamais (clés d'API externes que vous ne pouvez pas faire pivoter), vous devez au minimum documenter leur date d'expiration connue et mettre des rappels d'au moins trois mois avant de redéployer avec une nouvelle clé.
La révocation d'un secret compromis doit être possible en moins d'une minute. Si une clé AWS est fuie, vous devez pouvoir la désactiver immédiatement, redéployer les services avec une nouvelle clé de Secrets Manager, et auditer rétroactivement qui l'a utilisée et quand. Les équipes modernes automatisent même cette étape : une alerte CloudTrail détecte un secret anormal, déclenche une Lambda qui invalide la clé, déclenche un redéploiement des pods EKS avec une nouvelle clé. Tout cela en quelques secondes, sans intervention manuelle.
Enfin, documentez vos principes d'accès aux secrets dans une politique d'entreprise ou un ADR (Architecture Decision Record) : qui peut lire quel secret, sur quels environnements, par quel service, via quel processus de demande ? Les équipes sans cette politique finissent avec un mille-feuille de secrets qui ne sont supprimés jamais ("au cas où") et dont plus personne ne sait à qui ils servent. Le nettoyage régulier (tous les trimestres) des secrets inutilisés, confirmé par les logs CloudTrail, prévient cette dérive.
Intégration avec Terraform et Infrastructure-as-Code : déclarer vos secrets sans les exposer
Quand vous gérez votre infrastructure via Terraform ou CloudFormation, vous devez déclarer que votre application a besoin d'un secret sans écrire le secret lui-même en clair dans le code. Le pattern Terraform standard est de séparer la déclaration du secret (créer une ressource Secrets Manager vide) de son CONTENU (géré soit manuellement, soit via une Lambda de rotation, soit chargé depuis une source sécurisée). Votre code Terraform dit : "créez un secret nommé 'prod-db-password' avec une clé de chiffrement KMS dédiée", mais ne dit jamais "la valeur est ABC123".
Une deuxième approche, plus commune, est d'utiliser la source de données Terraform aws_secretsmanager_secret_version pour LIRE un secret existant et l'injecter dans une ressource (par exemple, passer le mot de passe en variable d'environnement à une tâche ECS). Cela suppose que le secret a été créé et rempli par un processus hors Terraform (une Lambda de bootstrap, un script SQL, ou un incident human). Votre Terraform dit alors : "lis le secret nommé X depuis Secrets Manager et passe sa valeur au déploiement". Terraform lui-même ne voit jamais la valeur en clair ; seul l'état Terraform ne chiffré par defaut contient des références aux ARN des secrets.
Le risque majeur ici est que l'état Terraform soit poussé en clair sur un dépôt ou stocké sur un backend sans chiffrement. Pour l'éviter : chiffrez votre état Terraform (S3 avec server-side encryption + DynamoDB pour le verrou), restreignez l'accès en lecture au backend AWS (IAM), et utilisez terraform remote state pour que personne ne télécharge l'état localement. Si vous utilisez Terraform Cloud, AWS State Store, ou tout autre backend managed, vérifiez que le chiffrement et l'accès sont activés par défaut.
Un anti-pattern courant : écrire le secret dans un fichier .tfvars, commiter ce fichier dans le dépôt (même en privé), ou le passer en ligne de commande où il apparaît dans l'historique shell. À la place, fournissez les secrets via des variables d'environnement TF_VAR_*, Terraform Cloud/Enterprise avec des variables sensibles UI-only, ou un outil de gestion d'env comme direnv ou sops (Simple Ops Secrets) qui chiffre les fichiers de secrets avec KMS ou GPG.
Quand vous travaillez en équipe, cela signifie que un(e) personne (par exemple un(e) DevOps senior) crée les secrets manuellement ou les sème via une Lambda au démarrage du compte AWS, tout le reste de l'équipe utilise Terraform avec une source de données pour les LIRE et les INJECTER, sans jamais voir la valeur. Un nouveau membre de l'équipe peut cloner le dépôt, faire terraform plan, et déployer sans accéder aux vrais secrets : son IDE n'affiche que des références, pas des mots de passe. Cette séparation rend le code publiquement partageable (exemple open-source) sans risquer une fuite.
Audit de vos pratiques actuelles et étapes concrètes pour migrer vers un modèle sécurisé
Si vous lisez cet article, c'est probablement parce que vous sentez une dette de sécurité dans votre gestion des secrets. Voici comment diagnostiquer votre situation actuelle et planifier la migration sans bloquer vos déploiements.
Commencez par un audit des secrets en clair. Cherchez en grep dans votre code : secrets codés en dur, fichiers .env committes, variables hardcoded dans des scripts de déploiement, clés AWS stockées sur des instances EC2 sans rôle IAM. Utilisez des outils comme TruffleHog ou git-secrets pour scraper votre historique Git et détecter les patterns de clés AWS, clés SSH, tokens JWT. Même si vous supprimez une clé du dernier commit, elle reste dans l'historique Git jusqu'à une réécriture de branche complète. Documentez ce que vous trouvez : urgence (production ? développement ?), usage actuel (qui dépend de cette clé ?), risque d'exposition connu ?
Deuxièmement, auditez vos pipelines existants. Comment les secrets sont-ils actuellement injectés ? Variables d'environnement en clair ? Fichiers passés via SCP ? Credentials stockées dans Jenkins ? Secrets dans les logs ? Tracez le flux complet : où commence la clé, par où transitte-elle, qui y a accès à chaque étape, où finit-elle ? Notez les goulots d'étranglement (un secret partagé entre dix services, une seule clé AWS pour tous les déploiements).
Troisièmement, classez par impact et sécurité. Identifiez les 5-10 secrets les plus critiques (accès base de données production, clés AWS pour S3 critique, certifications) et commencez par CEUX-LÀ. Migrez d'abord les secrets de production qui impactent tous les déploiements, ensuite les secrets de staging, puis les secrets de développement. Pour chaque secret, créez une ressource Secrets Manager, attribuez une clé KMS dédiée, configurez une policy IAM restrictive, et testez l'injection dans un déploiement non-critique avant de passer en production.
Quatrièmement, mettez à jour votre pipeline. Si vous utilisez GitHub Actions, remplacez les secrets stockées dans GitHub Settings par une connexion OIDC vers AWS, puis récupérez les vrais secrets depuis Secrets Manager. Si vous utilisez GitLab CI, même approche : OIDC ou ID tokens vers AWS. Pour Jenkins sur premise ou Terraform Cloud, utilisez un service d'émission de credentials (AWS STS avec OIDC, ou un Vault interne).
Enfin, établissez une gouvernance en continu. Activez CloudTrail pour tous les appels à Secrets Manager, mettez en place une alerte CloudWatch pour chaque lecture anormale, planifiez une révision trimestrielle des secrets inutilisés, et documentez qui peut demander l'accès à quel secret. Les meilleures équipes automatisent l'approbation (un formulaire qui envoie un ticket Slack, un manager l'approuve, une Lambda crée le secret et la policy IAM en 30 secondes).
Le calendrier type pour une scale-up : audit complet et priorités en 1-2 semaines, migration des 5-10 secrets critiques en 2-4 semaines (par batch de 1-2 secrets par sprint pour ne pas blocage de déploiement), mise à place des outils de gouvernance et audit en 2 semaines supplémentaires. Total : 1-2 mois pour passer d'une culture "secrets en clair" à "gestion centralisée et auditée". C'est un investissement court et bon, qui réduit masssivement le risque en cas de faille et vous prépare pour les audits de conformité futurs.