Un secret en clair dans Git est un secret compromis. Mots de passe de bases de données, tokens d’API, clés privées TLS, identifiants admin : tous doivent être chiffrés avant d’entrer dans un dépôt versionné. Ansible propose pour cela Ansible Vault, un mécanisme natif de chiffrement AES-256, complété par des intégrations vers des gestionnaires externes (HashiCorp Vault, OpenBao, Passbolt) quand l’équipe ou l’infrastructure le demandent. Le sujet revient à l’examen RHCE EX294 et conditionne la conformité (RGPD, PCI-DSS, ISO 27001) de toute infra automatisée.
Aller droit au but
Section intitulée « Aller droit au but »Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Chiffrer un fichier complet avec
ansible-vault encrypt. - Chiffrer une seule variable avec
ansible-vault encrypt_string(pattern recommandé). - Gérer plusieurs environnements avec
--vault-id dev@... --vault-id prod@.... - Séparer variables publiques (
main.yml) et secrets (vault.yml) au sein d’un même groupe. - Intégrer un secret manager externe : HashiCorp Vault, OpenBao, Passbolt.
- Sécuriser les mots de passe vault eux-mêmes (env var, keystore, AppRole).
Prérequis
Section intitulée « Prérequis »Avant cette section, vous devez avoir validé :
- Découvrir Ansible : architecture, push SSH, ansible.cfg.
- Premiers pas : premier playbook, debug.
- Variables et inventaires :
group_vars,host_vars, précédence. - Rôles Ansible :
defaults/,vars/, structure standard.
Mon retour d’expérience — pour ceux qui veulent comprendre
Section intitulée « Mon retour d’expérience — pour ceux qui veulent comprendre »Si l’une des cartes en haut de page ou la décision en 30 secondes vous a déjà orienté, c’est parfait — vous êtes parti sur le bon pied. La suite de cette page s’adresse à ceux qui veulent comprendre la philosophie de cette section avant de plonger : quels patterns je défends, quels patterns je vous interdis, et pourquoi. La gestion de secrets est l’endroit où un mauvais choix coûte le plus cher, et le plus longtemps — d’où l’insistance sur le « pourquoi », pas seulement sur le « comment ».
J’ai débuté sur Ansible avec un secrets.yml non chiffré dans le .gitignore — le pattern « par défaut » des tutos de l’époque. Trois ans plus tard, on retrouvait encore des credentials de prod dans des dépôts forkés par d’anciens stagiaires partis depuis longtemps. C’est ce genre d’incident qui fait basculer une équipe vers Vault — pas la lecture d’un guide. Les sections qui suivent compilent ce que je n’aurais jamais accepté de relâcher en production, pas ce qui « semble correct » dans la doc officielle.
Pourquoi chiffrer plutôt que cacher ?
Section intitulée « Pourquoi chiffrer plutôt que cacher ? »Une mauvaise habitude répandue : créer un fichier secrets.yml non chiffré et l’ajouter au .gitignore. Trois problèmes majeurs surgissent rapidement :
- Perte du fichier : un contributeur clone, configure son env, oublie de demander les secrets — le déploiement échoue silencieusement.
- Fuite par mégarde : un
git add -Amal calibré, un fichier renommé qui sort du.gitignore, et le secret atterrit sur GitHub public. - Pas d’audit : qui a accédé à quel secret quand ? Impossible à reconstituer sans intégration externe.
Un fichier chiffré avec Ansible Vault vit dans Git comme n’importe quel autre fichier. Il est versionné, diffable (au prix d’un coup de ansible-vault view), partagé via les permissions Git classiques, et son contenu reste protégé même en cas de fuite du dépôt — tant que le mot de passe vault, lui, est correctement isolé.
Le bon outil pour le bon secret
Section intitulée « Le bon outil pour le bon secret »Tous les secrets ne se valent pas. Choisir l’outil adapté évite la sur-ingénierie comme l’insuffisance.
| Type de secret | Outil recommandé | Raison |
|---|---|---|
| Mot de passe d’app, token API stable | Ansible Vault (encrypt_string) | Versionné, simple, suffit dans 80 % des cas. |
| Secrets multi-environnements (dev/prod) | --vault-id par env | Rotation isolée, mots de passe distincts. |
| Credentials DB dynamiques (TTL court) | HashiCorp Vault / OpenBao | Génération on-demand, lease automatique. |
| Mots de passe partagés entre humains | Passbolt | UI navigateur, OpenPGP, audit par utilisateur. |
| Certificats X.509 PKI internes | HashiCorp Vault PKI | Émission auto, rotation centralisée. |
| Secrets cloud (AWS, Azure, GCP) | Auth IAM / Workload Identity | Pas de credential statique du tout. |
Cette section traite les 4 premières lignes (Ansible Vault + HashiCorp Vault/OpenBao + Passbolt). Pour les certificats PKI et l’auth Cloud, voir les sections dédiées de la docs HashiCorp Vault et de chaque provider Cloud.
Ce que je défends pour la gestion de secrets
Section intitulée « Ce que je défends pour la gestion de secrets »Cinq positions tranchées que cette section assume — et qu’elle vous demande d’adopter avant de produire du code « secret-aware » :
encrypt_stringpar défaut, fichier complet en exception. Chiffrer un fichier entier rend les diffs Git illisibles, casse la revue de code et pousse les équipes àdecrypt → modifier → encryptau lieu de versionner proprement. Une variable sensible = un!vaultinline. Le fichier complet est réservé aux cas où tout le contenu est sensible (clé privée, certificat).- Préfixe
vault_*non négociable. Toute variable chiffrée porte ce préfixe (vault_db_password), exposée viadefaults/main.ymlen indirection (db_password: "{{ vault_db_password }}"). Sans cette convention, impossible de distinguer en revue un secret d’une variable normale — et impossible d’auditer. - Un
--vault-idpar environnement, dès le départ. Même sur un projet « simple », j’ouvre dev / staging / prod distincts. Migrer un projet single-vault vers multi-vault après coup est une corvée. Faites-le bien dès le jour 1, ça coûte 10 minutes. - Le mot de passe Vault n’est jamais un mot de passe. C’est une clé, générée aléatoirement (
openssl rand -base64 32), stockée dans~/.vault_password(chmod 0600) en local, en variable d’env CI/CD, en AppRole pour les bots. Aucun humain ne « tape » ce mot de passe. - Pattern hybride en production. Ansible Vault pour le statique versionné, HashiCorp Vault/OpenBao pour le dynamique runtime, Passbolt pour le partage humain. Une équipe mature utilise les trois, chacun sur son créneau — pas l’un à la place de l’autre.
Ce que je vous interdis
Section intitulée « Ce que je vous interdis »Cinq erreurs qui transforment Vault en illusion de sécurité — chacune vue plusieurs fois en mission, chacune coûteuse à corriger après coup :
- Commiter le
.vault_password. L’incident classique : un dev clone, met le mot de passe dans un fichier à la racine pour aller vite, oublie le.gitignore. Trois jours plus tard, le fichier est sur GitHub public. Ajoutez*.password*et.vault_password*au.gitignoreracine dès le commit initial. Faites ungit log --all --full-history -- .vault_passwordaprès chaque grosse incident pour vous rassurer. --ask-vault-passen CI/CD. Pratique en local, inutilisable dans un pipeline non interactif. Les équipes finissent par mettre le mot de passe en clair dans une variable d’env GitLab non masquée. En CI : un fichier en mode0600injecté depuis un secret manager, point. Si votre runner ne sait pas faire, changez de runner.- Tout chiffrer, par principe. J’ai vu un projet où tout
inventory/hosts.ymlétait chiffré « par sécurité ». Résultat : impossible de lire les hostnames sansansible-vault view, debug atroce, onboarding catastrophique. On chiffre les vraies données sensibles — pas les noms de machines, pas les paths, pas les ports. no_log: falsesur une tâche manipulant un secret. La tâche journalise le secret dans la sortie de l’agent CI ou dans le sudo log. Indexable par défaut par Splunk ou la stack ELK. Toute tâche qui touche un secret porteno_log: true— y compris en debug, où vous remplacez par un fingerprint (ansible-vault encrypt_stringretourne un hash, pas le secret).- Un seul mot de passe Vault pour toute l’organisation. Le sysadmin qui le connaissait part, et l’équipe ne sait plus comment rotater 50 rôles d’un coup. Un vault-id par périmètre fonctionnel (dev/prod, équipe A / équipe B). La rotation devient locale, l’audit devient possible, le départ devient un non-événement.
Le parcours en 4 phases
Section intitulée « Le parcours en 4 phases »Le parcours est séquentiel. Chaque phase suppose acquise la précédente.
Phase 1 — Maîtriser Ansible Vault natif
Section intitulée « Phase 1 — Maîtriser Ansible Vault natif »L’objectif est d’incorporer Vault au quotidien : créer, lire, modifier, déchiffrer un fichier ou une variable. Trois pages :
Phase 2 — Multi-environnements et patterns d’équipe
Section intitulée « Phase 2 — Multi-environnements et patterns d’équipe »Quand l’organisation grandit, un seul mot de passe Vault ne suffit plus : il faut isoler dev / staging / prod, organiser les fichiers, partager proprement entre rôles.
Phase 3 — Externaliser vers un secret manager
Section intitulée « Phase 3 — Externaliser vers un secret manager »Pour les secrets dynamiques, rotables centralement, ou soumis à audit : déléguer le stockage à un service dédié.
Phase 4 — Sécuriser le mot de passe vault lui-même
Section intitulée « Phase 4 — Sécuriser le mot de passe vault lui-même »Tous les patterns reposent sur un mot de passe ou une clé quelque part. Cette dernière étape couvre les bonnes pratiques : ANSIBLE_VAULT_PASSWORD_FILE, AppRole CI/CD, gnome-keyring, GitHub Secrets, AWS KMS — abordés dans chaque page concernée selon le contexte.
Ansible Vault vs gestionnaires externes — quand bascule-t-on ?
Section intitulée « Ansible Vault vs gestionnaires externes — quand bascule-t-on ? »Démarrer avec Ansible Vault natif est le bon choix dans 80 % des projets. Il est gratuit, intégré, ne nécessite aucune infrastructure supplémentaire, et résout le besoin de base : secrets versionnés et chiffrés.
On bascule vers un secret manager externe quand au moins une de ces conditions devient critique :
- Rotation centralisée : devoir rechiffrer N rôles à chaque changement de mot de passe DB est insupportable.
- Secrets dynamiques : credentials DB éphémères (PostgreSQL, MongoDB), tokens AWS STS, certificats à TTL court.
- Audit fin : qui a accédé à quel secret quand, depuis quelle IP, pour quelle action.
- Partage humain : équipe non-DevOps qui doit consulter un mot de passe via UI web.
- Compliance : SOC 2, PCI-DSS, HIPAA exigeant un coffre dédié certifié.
Le pattern hybride — fréquent en production — combine les deux : Ansible Vault pour les fichiers de configuration sensibles versionnés, HashiCorp Vault pour les secrets dynamiques runtime, Passbolt pour les mots de passe partagés humains. Chaque outil sur son créneau.
À retenir
Section intitulée « À retenir »- Ansible Vault chiffre fichiers ou variables avec AES-256 ; suffit dans la majorité des projets.
encrypt_stringest préférable à un fichier complet chiffré — diffs Git restent lisibles.--vault-id <label>@<source>isole les environnements et permet la rotation par env.- Pattern
defaults/main.yml+vars/main.ymldans les rôles : variables publiques côtédefaults, secrets chiffrés côtévars, indirection viavault_*. - HashiCorp Vault / OpenBao : secrets dynamiques + audit + rotation centralisée, API compatible entre les deux.
- Passbolt complète Vault pour le partage humain (équipe non-DevOps) avec un workflow UI navigateur + OpenPGP.
- Le pattern hybride (Ansible Vault + HashiCorp Vault + Passbolt) est la norme en production en 2026.