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, à faire tourner et à révoquer proprement.
Ce guide vous aide à poser un modèle simple avant de parler d’outils : ce qui doit rester dans le code, ce qui doit rester hors du code, qui doit pouvoir 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.
Ce que vous allez apprendre
Section intitulée « 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 ;
- mettre en place des règles simples de rotation, d’accès et de revue.
Pourquoi les secrets cassent vite une pratique IaC
Section intitulée « Pourquoi les secrets cassent 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, 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.
Ce qu’on appelle un secret en IaC
Section intitulée « Ce qu’on appelle 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 |
Ce point est important pour les débutants : un secret n’est pas seulement un mot de passe humain. Un token très court, 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 vraiment
Section intitulée « Où les secrets fuient 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.
1. Le code et les fichiers associés
Section intitulée « 1. Le code et les fichiers associés »Le cas le plus évident est le secret écrit directement 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
Section intitulée « 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.
3. Le runtime et les environnements d’exécution
Section intitulée « 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.
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
Section intitulée « 4. L’état et les métadonnées de changement »Une pratique IaC mature doit aussi se demander si un secret peut se retrouver dans les métadonnées de travail : état, plan, backend, sauvegarde, journal de debug. C’est une surface moins intuitive pour les débutants, mais souvent plus grave parce qu’elle concentre l’inventaire technique du système.
Le bon modèle : séparer code, config et accès
Section intitulée « Le bon modèle : séparer code, config et accès »Pour avancer sans complexité inutile, retenez ce modèle simple.
-
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.
-
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é.
-
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.
-
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 ?
Section intitulée « Où le secret doit-il vivre ? »Il n’existe pas une seule réponse valable partout. En revanche, il existe une hiérarchie saine.
| 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 |
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.
Rotation, expiration et révocation : les trois règles qui changent tout
Section intitulée « Rotation, expiration et révocation : les trois règles qui changent 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 |
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.
Ce qu’une pull request ou un pipeline doit vérifier
Section intitulée « Ce qu’une pull request ou un pipeline doit vérifier »Avant fusion ou déploiement, une base saine consiste à contrôler les points suivants.
| 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 le blast radius |
| La rotation et la révocation sont-elles documentées ? | améliore la réponse à incident |
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.
Ce qu’il faut éviter dès maintenant
Section intitulée « Ce qu’il faut éviter dès maintenant »Croire qu’un masquage visuel suffit
Section intitulée « Croire qu’un masquage visuel suffit »Une valeur cachée dans une interface ou un log n’est pas forcément absente des plans, artefacts ou sauvegardes. Le masquage réduit l’exposition visuelle, pas nécessairement la persistance.
Utiliser un seul secret partagé partout
Section intitulée « Utiliser un seul secret partagé partout »Une clé unique pour plusieurs environnements, plusieurs pipelines ou plusieurs services agrandit le blast radius. Une compromission locale devient alors une compromission globale.
Traiter le pipeline comme un coffre-fort naturel
Section intitulée « 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
Section intitulée « 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
Section intitulée « À 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.
- 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.