Gérer les secrets en IaC

En Infrastructure as Code, le problème n'est pas seulement d'éviter un mot de passe commité dans Git. Le vrai risque apparaît quand un secret traverse trop d'endroits en même temps : dépôt, fichier de variables, pipeline, plan d'exécution, logs, artefacts ou runtime applicatif. Plus il circule, plus il devient difficile à contrôler, à renouveler et à révoquer proprement.

Cette leçon pose un modèle simple avant de parler d'outils : ce qui reste dans le code, ce qui reste hors du code, qui peut lire un secret, et quand ce secret devrait disparaître. C'est cette clarification qui évite de bricoler des exceptions dans chaque dépôt ou chaque pipeline.

Elle s'adresse à une personne qui connaît Git et lit du YAML, et qui a lu État, plan et réconciliation : le state et le plan y sont définis, ici on regarde ce qu'ils peuvent faire fuiter. Les tableaux et schémas sont des supports de lecture, sans commande à exécuter. Savoir quelle identité machine a le droit d'appliquer l'infrastructure est un autre sujet, traité dans Identité et droits du moteur IaC, une leçon facultative.

Ce que vous allez apprendre

• comprendre où les secrets apparaissent réellement dans une chaîne IaC ;
• choisir un mode de stockage et d'injection cohérent selon le risque ;
• savoir pourquoi le state est une surface d'exposition, et quels outils n'en ont pas ;
• mettre en place des règles simples de rotation, d'accès et de revue.

Pourquoi un secret casse-t-il vite une pratique IaC ?

Dans un projet IaC, un secret n'est presque jamais isolé. Une même valeur peut être copiée dans un fichier de variables, injectée dans un pipeline (la chaîne automatique qui construit et déploie), affichée dans un log de débogage, puis réutilisée par un service de production. À partir de là, l'équipe ne sait plus vraiment :

• qui a accès à cette valeur ;
• quelle version est encore valide ;
• où la révoquer en cas d'incident ;
• si elle a fuité dans un artefact ou dans un historique Git.

Le problème vient souvent d'un mauvais modèle mental. Beaucoup d'équipes pensent encore : "un secret, c'est juste une variable à cacher". En réalité, un secret est surtout un accès qu'il faut limiter dans le temps, dans le périmètre et dans les surfaces où il peut apparaître.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Qu'appelle-t-on un secret en IaC ?

Dans ce contexte, un secret est toute donnée qui donne ou débloque un accès :

Type de donnée	Exemple	Pourquoi c'est sensible
Identifiant applicatif	clé API, jeton d'accès	permet d'appeler un service externe
Accès système	mot de passe, clé SSH	ouvre une session ou une exécution distante
Secret de plateforme	certificat, clé privée, token d'orchestrateur	donne accès à une couche centrale
Secret de bootstrap	identifiant temporaire de pipeline ou de déploiement	permet d'aller chercher d'autres accès

Glissez pour voir

Un secret n'est pas seulement un mot de passe humain. Un token (un jeton d'accès, souvent de courte durée), un certificat machine ou une clé de chiffrement sont aussi des secrets, parfois plus critiques qu'un mot de passe utilisateur.

Où les secrets fuient-ils vraiment ?

Le dépôt Git n'est qu'une des surfaces de fuite. En pratique, les erreurs les plus fréquentes se répartissent en quatre zones. Les trois premières se traitent ci-dessous ; la quatrième, le state, a sa propre section plus bas.

1. Le code et les fichiers associés

Le cas le plus évident est le secret écrit en dur dans le code, dans un fichier de variables ou dans un template. Cela inclut aussi les copies temporaires laissées dans un exemple, un script de test ou un fichier local finalement versionné.

Le principe de séparation entre code et configuration reste un bon point de départ : si une valeur change selon l'environnement ou donne accès à un système, elle n'a rien à faire en dur dans le dépôt. Mais cette séparation ne règle pas tout, car une variable d'environnement peut elle aussi fuir dans un shell, un dump mémoire ou un log.

2. Le pipeline et les artefacts

Un pipeline est souvent traité comme une zone de confiance. C'est une erreur classique. Si un secret passe dans :

• une variable de job trop large ;
• un log verbeux ;
• un plan sauvegardé ;
• un artefact partagé ;
• une image construite trop tôt ;

alors il sort déjà de son périmètre initial.

Point de vigilance

Un secret stocké dans l'outil de CI/CD est parfois acceptable comme point de passage, mais cela ne doit pas devenir le coffre-fort principal par défaut. Plus le pipeline voit de secrets durables, plus son niveau de confiance doit se rapprocher de celui d'un système de production.

3. Le runtime et les environnements d'exécution

Un secret peut être injecté au bon moment, puis rester trop visible ensuite. C'est ce qui arrive quand il finit dans des variables exposées à trop de processus, dans un fichier persistant sur disque, ou dans un mécanisme partagé entre plusieurs workloads (les applications qui tournent).

La bonne question n'est donc pas seulement "comment injecter le secret ?", mais aussi "combien de temps reste-t-il visible, et pour qui ?".

4. L'état et les métadonnées de changement

Une pratique IaC mature se demande aussi si un secret peut se retrouver dans les métadonnées de travail : state (la mémoire de l'outil), plan (l'aperçu des changements), backend (le stockage partagé du state), sauvegarde, journal de debug. C'est la surface la moins intuitive pour un débutant, et souvent la plus grave parce qu'elle concentre l'inventaire technique du système. La section suivante la détaille.

Pourquoi le state est-il une surface d'exposition ?

Le state n'est pas un simple fichier technique : c'est la mémoire de l'outil, et elle contient souvent plus que ce que le code montre. Dans le scénario de la formation (une application web avec deux VM, une base, un réseau et un DNS), avec Terraform, le mot de passe initial de la base, passé en variable à la création, peut se retrouver en clair dans le state, alors qu'il n'est écrit nulle part dans le dépôt. La leçon État, plan et réconciliation compare les quatre familles de mémoire ; voici ce que chacune implique côté fuite.

• Pas de state du tout : un outil qui pousse la configuration, comme Ansible ou Salt en mode push, relit l'état réel des machines à chaque exécution. Il n'a pas de fichier à protéger, mais ses inventaires, ses journaux, son mode --diff et, pour Salt, le cache de jobs du master (job_cache, activé par défaut) peuvent exposer des valeurs sensibles.
• State géré par un service : avec CloudFormation, l'état d'une pile vit chez le fournisseur. Aucun fichier à manipuler, mais le droit de lire la pile et ses sorties reste à encadrer.
• L'API comme état : avec Crossplane, c'est le cluster Kubernetes qui sert d'état. Le protéger revient à protéger l'accès à l'API et au stockage du cluster.
• Un fichier de state : avec Terraform, OpenTofu ou Pulumi, l'état est un fichier (ou un objet de stockage) que l'outil lit et écrit. C'est le cas qui occupe le reste de cette section.

Que révèle un state, même sans mot de passe ?

Un débutant imagine qu'un state ne contient que des identifiants techniques. Il expose en réalité cinq catégories d'information, et seule la dernière est un secret au sens strict. Le tableau donne, pour chacune, pourquoi elle intéresse un attaquant.

Catégorie	Exemples	Pourquoi c'est sensible
Topologie	réseaux, sous-réseaux, rôles, endpoints	aide à comprendre l'architecture
Identifiants d'objets	IDs cloud, chemins, noms, URLs	facilite le pivot ou l'énumération
Configuration	tailles, régions, drapeaux de sécurité	révèle les choix de durcissement ou leurs absences
Sorties utiles	IP, chaînes de connexion, certificats	donne des points d'entrée directs
Valeurs sensibles	mots de passe initiaux, jetons, clés	expose un accès immédiat

Glissez pour voir

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Même sans valeur secrète brute, un state reste une source de renseignement opérationnel : il suffit à accélérer une compromission ou une mauvaise manipulation. Le schéma montre les quatre endroits où cette information circule, détaillés ensuite.

Où fuit-il autour du state ?

Il faut regarder toute la chaîne, pas seulement le fichier principal.

• Le state local, laissé sur un poste, dans une archive partagée ou versionné par erreur, avec ses copies de secours oubliées.
• Le backend distant (voir Backend S3 et remote state) : il aide la collaboration, mais ne rend pas l'état sain si les accès sont trop larges, le chiffrement absent ou les sauvegardes mal contrôlées. Le problème est simplement déplacé.
• Les plans et artefacts : un plan enregistré, un artefact de CI (un fichier produit et conservé par le pipeline), un export JSON ou un journal de debug capturent tout ou partie des mêmes informations.
• Les identifiants du backend lui-même, laissés dans le dépôt, dans une commande shell historisée ou dans un fichier auxiliaire non traité comme sensible.

Masquer une valeur, est-ce l'empêcher d'être stockée ?

Non, et la confusion est fréquente : cacher une valeur dans une sortie de la CLI, éviter qu'elle apparaisse dans un diff, et empêcher qu'elle soit écrite dans le state, un plan ou un artefact sont trois niveaux différents. Une donnée masquée à l'écran peut quand même se retrouver dans le state ; pour le cas Terraform, voir Comprendre le state Terraform et le masquage dans sensitive en Terraform : masquer, propager, et ses pièges.

La meilleure parade est de ne pas persister la valeur. Un mot de passe utilisé seulement pour créer une ressource, une valeur de bootstrap, un secret court ou une donnée de connexion que le consommateur peut récupérer lui-même plus tard n'ont pas à vivre dans l'état durable. Terraform sait désormais produire des valeurs éphémères et des arguments write-only qui évitent l'écriture dans le state. La question à poser n'est donc pas seulement « comment cacher la valeur ? », mais « faut-il vraiment la persister ? ».

Comment protéger le state ?

La protection repose sur cinq couches complémentaires. Aucune ne suffit seule.

1. Sortir l'état des postes quand le travail devient collectif

   Dès que l'équipe est à plusieurs ou qu'un pipeline applique les changements, l'état vit dans un stockage partagé pensé pour la collaboration, pas dans un fichier local recopié à la main.

2. Chiffrer et journaliser l'accès

   Le stockage protège les données au repos et en transit, et permet de savoir qui a lu, modifié ou restauré l'état.

3. Limiter les lecteurs réels

   Tout le monde n'a pas besoin de télécharger le state complet : moindre privilège, surtout en production. Distribuer un export complet pour « aider au diagnostic » élargit le périmètre de confiance.

4. Verrouiller les opérations concurrentes

   Un état partagé sans verrou devient un problème d'intégrité autant que de sécurité ; voir Verrouiller le state Terraform.

5. Tester sauvegarde et restauration

   Un bon backend ne remplace pas une procédure de récupération rejouée ; voir Sauvegarder et restaurer le state.

Comment séparer code, configuration et accès ?

Pour avancer sans complexité inutile, retenez ce modèle simple.

1. Déclarer le besoin d'accès, pas la valeur secrète

   Le dépôt doit décrire qu'un service a besoin d'un accès à une base, à un registre ou à une API. Il ne doit pas devenir l'endroit où la valeur circule librement.

2. Stocker la valeur dans une zone dédiée

   La valeur secrète doit vivre dans un mécanisme pensé pour cela : coffre-fort, gestionnaire de secrets, chiffrement applicatif ou, dans certains cas, fichier chiffré strictement encadré.

3. Réduire au maximum les secrets durables

   Dès que c'est possible, préférez des accès courts, spécifiques et renouvelables plutôt qu'une même clé partagée pendant des mois.

4. Faire récupérer le secret par le bon acteur

   Plus le consommateur final récupère lui-même son secret au moment utile, moins la chaîne intermédiaire a besoin de le voir.

Où le secret doit-il vivre ?

Il n'existe pas une seule réponse valable partout. En revanche, il existe une hiérarchie saine, du pire au meilleur choix par défaut : le tableau donne, pour chaque option, quand elle a du sens et sa limite principale.

Option	Quand elle a du sens	Limite principale
Dans le code	pratiquement jamais	fuite immédiate et durable
Dans l'outil de CI/CD	secret de passage, périmètre réduit, durée courte	exposition aux mainteneurs, aux logs et aux jobs
Dans un gestionnaire de secrets	cas général recommandé	demande une vraie gestion d'identité et d'audit
Dans un fichier chiffré versionné	besoin GitOps ou revue déclarative	la discipline de clés et de déchiffrement devient centrale
Récupération au runtime par identité machine	charges sensibles ou fortement industrialisées	demande une plateforme plus mûre

Glissez pour voir

Le point important est le suivant : sortir un secret du dépôt n'est qu'une première étape. Si vous le déplacez simplement vers un pipeline ou un fichier partagé, vous avez déplacé le risque, pas résolu le problème. Pour la vue d'ensemble, voir Gestion des secrets : réduire les risques ; pour les fuites dans l'historique Git, Secrets dans le code Git ; pour la rotation et la révocation en détail, Cycle de vie d'un secret.

Pourquoi rotation, expiration et révocation changent-elles tout ?

Un secret bien stocké mais jamais renouvelé reste un mauvais secret. Pour une pratique IaC durable, il faut penser en cycle de vie.

Règle	Ce qu'elle change concrètement
Rotation	réduit la durée d'exposition après une fuite
Expiration	évite qu'un accès oublié reste valable indéfiniment
Révocation	permet de couper vite en cas d'incident

Glissez pour voir

Les équipes débutantes se concentrent souvent sur le stockage. Les équipes plus matures regardent surtout la vitesse à laquelle elles peuvent remplacer un secret compromis sans casser toute la chaîne de livraison.

Que vérifier dans une pull request ou un pipeline ?

Avant fusion ou déploiement, une base saine consiste à contrôler six points. Le tableau donne la raison de chacun, pour que la vérification ne devienne pas un rituel.

Vérification	Pourquoi elle compte
Un secret en clair apparaît-il dans le diff ?	évite la fuite la plus évidente
Un exemple ou un fichier local a-t-il été versionné par erreur ?	réduit les fuites accidentelles
Le pipeline imprime-t-il des variables sensibles ?	limite les expositions invisibles
Le secret est-il durable alors qu'un accès court serait possible ?	réduit l'étendue des dégâts en cas de fuite
La rotation et la révocation sont-elles documentées ?	améliore la réponse à incident
Un plan, un export ou un artefact contenant des valeurs sensibles est-il conservé ou partagé ?	évite de dupliquer le state hors de son périmètre

Glissez pour voir

Si l'équipe ne sait pas répondre rapidement à la question "où révoque-t-on ce secret ?", c'est déjà un signal de dette.

Quelles erreurs éviter dès maintenant ?

Le masquage visuel et le backend distant qui « règle tout » ont été traités avec le state ; trois autres erreurs reviennent.

Utiliser un seul secret partagé partout

Une clé unique pour plusieurs environnements, plusieurs pipelines ou plusieurs services agrandit le blast radius (l'étendue des dégâts possibles si un secret fuit). Une compromission locale devient alors une compromission globale.

Traiter le pipeline comme un coffre-fort naturel

Le pipeline a souvent besoin de secrets, mais il ne doit pas devenir l'endroit où toutes les valeurs de production vivent longtemps et sans contrôle fin.

Oublier le runtime

Certaines équipes sécurisent le dépôt, puis laissent les secrets visibles dans les processus, dans des fichiers persistants ou dans des logs applicatifs. Le problème est simplement déplacé plus loin dans la chaîne.

À retenir

• Un secret en IaC n'est pas seulement une variable à masquer, c'est un accès à limiter dans le temps, le périmètre et les surfaces d'exposition.
• Le dépôt Git n'est qu'une surface de fuite parmi d'autres : pipeline, runtime, artefacts et état comptent aussi.
• Tous les outils n'ont pas de state : Ansible et Salt en mode push n'en ont pas, CloudFormation le confie au service, Crossplane utilise l'API Kubernetes.
• Un state révèle une cartographie utile même sans secret brut ; le protéger demande stockage partagé, chiffrement, accès limités, verrou et sauvegarde testée.
• Masquer une valeur en sortie ne garantit pas qu'elle n'est pas stockée : mieux vaut ne pas la persister.
• Sortir les secrets du code est nécessaire, mais pas suffisant.
• Une pratique saine réduit les secrets durables et pousse la récupération au plus près du consommateur final.
• Rotation, expiration et révocation comptent autant que le stockage initial.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →