TL;DR — Résumé Rapide
Ansible Vault chiffre les secrets dans les playbooks. Apprenez vault create, encrypt_string, vault IDs, integration CI/CD et rotation des mots de passe.
Stocker des mots de passe de bases de donnees, des cles API et des cles privees SSL en texte clair dans vos playbooks Ansible est l’une des erreurs de securite les plus courantes dans l’automatisation des infrastructures. Une fois qu’un secret arrive non chiffre dans un depot git, il est effectivement compromis — l’historique git persiste indefiniment, et toute personne ayant un acces en lecture au depot peut le recuperer. Ansible Vault resout ce probleme en chiffrant les secrets directement dans votre depot avec AES-256, vous permettant de commiter des fichiers de credentials chiffres aux cotes de vos playbooks sans rien exposer de sensible.
Prerequis
Avant de travailler avec ce guide, vous devez avoir :
- Ansible 2.8 ou ulterieur installe sur votre noeud de controle (
ansible --versionpour verifier) - Familiarite de base avec les playbooks Ansible et la structure des repertoires group_vars
- Un projet Ansible existant avec un inventaire et au moins un playbook
- Un editeur de texte configure comme votre
$EDITOR(nano, vim ou VS Code) - Pour les sections CI/CD : un pipeline GitHub Actions, GitLab CI ou Jenkins que vous pouvez modifier
Debutant avec Ansible ? Lisez d’abord notre guide Ansible pour debutants pour configurer la structure de votre projet avant d’ajouter Vault.
Pourquoi les Secrets en Texte Clair sont Dangereux
Chaque secret stocke en texte clair dans un depot git comporte le meme risque : l’exposition. Considerez ce qui se retrouve typiquement dans les fichiers de variables Ansible sans Vault :
- Mots de passe root de bases de donnees dans
group_vars/dbservers.yml - Cles d’acces AWS dans
host_vars/deploy.yml - Credentials SMTP dans
roles/notifications/defaults/main.yml - Contenu de cle privee SSL dans un bloc
vars:dans un playbook
L’un des evenements suivants expose ces secrets immediatement : un depot accidentellement rendu public, un compte GitHub d’un contributeur compromis, un log CI/CD fuite, ou un ancien employe mecontent. Ansible Vault empeche cela en garantissant que les fichiers stockes dans git ne contiennent que du texte chiffre AES-256, pas les valeurs reelles des secrets.
Le mot de passe du vault lui-meme n’entre jamais dans votre depot. Il reste dans votre tete, dans un gestionnaire de mots de passe, ou dans votre gestionnaire de secrets CI/CD — separe du code.
Creer des Fichiers Chiffres avec ansible-vault create
Le sous-commande create ouvre votre $EDITOR configure avec un fichier vide, vous laisse saisir vos secrets, et sauvegarde le fichier chiffre a la fermeture de l’editeur :
ansible-vault create group_vars/all/vault.ymlUn nouveau mot de passe de vault vous sera demande (deux fois pour confirmation). L’editeur s’ouvre. Saisissez vos secrets :
vault_db_password: "Tr0ub4dor&3"
vault_db_root_password: "R4nd0mS33d#9"
vault_api_key: "sk-live-abc123def456ghi789"
vault_smtp_password: "M@ilS3rv1c3P@ss"
vault_ssl_private_key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA3cH7...
-----END RSA PRIVATE KEY-----Sauvegardez et fermez. Le fichier sur disque ne contient maintenant que le blob chiffre :
$ANSIBLE_VAULT;1.1;AES256
66386439653763616335616230333934356262313032393132376163633335636630
34663437326664303537373561373039636131336531353364386530636431343739
...Modifier et visualiser les fichiers chiffres
# Ouvrir dans l'editeur pour modifications
ansible-vault edit group_vars/all/vault.yml
# Afficher le contenu dechiffre sans modifier
ansible-vault view group_vars/all/vault.yml
# Chiffrer un fichier texte clair existant
ansible-vault encrypt secrets.yml
# Dechiffrer un fichier en texte clair (utiliser avec prudence)
ansible-vault decrypt secrets.ymlChiffrer des Variables Individuelles avec encrypt_string
Parfois vous voulez un seul secret dans un fichier non vault — peut-etre parce que vous voulez que le contexte environnant soit visible sans tout dechiffrer. Le sous-commande encrypt_string genere une valeur chiffree que vous pouvez coller directement dans n’importe quel fichier YAML :
ansible-vault encrypt_string --name 'vault_stripe_key' 'sk_live_abc123xyz'Sortie :
vault_stripe_key: !vault |
$ANSIBLE_VAULT;1.1;AES256
66653465346564383664396631316639
37313739623731633864333736396230
...Collez ce bloc directement dans n’importe quel fichier YAML de variables. Ansible le dechiffre de maniere transparente a l’execution, de la meme facon qu’il gere un fichier vault entierement chiffre.
Quand utiliser encrypt_string vs fichiers chiffres :
| Approche | Utiliser quand |
|---|---|
ansible-vault create vault.yml | La plupart des cas — garde les secrets organises, facile a auditer |
encrypt_string | Secret unique dans un fichier principalement en clair; secrets inline dans les roles |
| Playbook entier chiffre | Rarement necessaire ; nuit a la lisibilite |
Vault IDs : Plusieurs Mots de Passe pour Differents Ensembles de Secrets
Les vault IDs vous permettent d’etiqueter le contenu chiffre pour qu’Ansible sache quel mot de passe appliquer. C’est essentiel quand staging et production utilisent des mots de passe differents, ou quand vous voulez faire une rotation d’un mot de passe sans tout re-chiffrer.
Chiffrer avec un vault ID
# Chiffrer avec un vault ID nomme
ansible-vault create --vault-id prod@prompt group_vars/production/vault.yml
ansible-vault create --vault-id staging@prompt group_vars/staging/vault.yml
# Ou pointer vers un fichier de mot de passe
ansible-vault create --vault-id prod@~/.vault_prod group_vars/production/vault.ymlDechiffrer avec plusieurs vault IDs
ansible-playbook site.yml \
--vault-id prod@~/.vault_prod \
--vault-id staging@~/.vault_stagingAnsible fait correspondre automatiquement chaque bloc chiffre a son etiquette de vault ID et utilise le bon mot de passe. Le contenu chiffre sans vault ID explicite utilise par defaut l’etiquette default.
Integration CI/CD avec —vault-password-file
Les invites de mot de passe interactives bloquent les pipelines automatises. Le flag --vault-password-file accepte un chemin vers un fichier contenant uniquement le mot de passe du vault, permettant une execution entierement non interactive.
Exemple avec GitHub Actions
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Installer Ansible
run: pip install ansible
- name: Ecrire le mot de passe vault dans un fichier
run: echo "${{ secrets.ANSIBLE_VAULT_PASSWORD }}" > ~/.vault_pass
- name: Executer le playbook
run: |
ansible-playbook -i inventory/production site.yml \
--vault-password-file ~/.vault_pass
- name: Supprimer le fichier de mot de passe vault
if: always()
run: rm -f ~/.vault_passStockez ANSIBLE_VAULT_PASSWORD dans les secrets GitHub Actions du depot (Parametres → Secrets → Actions). Le mot de passe du vault n’apparait jamais dans les logs car GitHub masque les valeurs des secrets.
Exemple avec GitLab CI
# .gitlab-ci.yml
deploy:
script:
- echo "$ANSIBLE_VAULT_PASSWORD" > ~/.vault_pass
- ansible-playbook -i inventory/production site.yml --vault-password-file ~/.vault_pass
- rm -f ~/.vault_pass
variables:
ANSIBLE_VAULT_PASSWORD: $ANSIBLE_VAULT_PASSWORDUtiliser un script de mot de passe vault
Pour les mots de passe vault dynamiques (recuperes depuis HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault a l’execution), creez un script executable qui retourne le mot de passe :
#!/bin/bash
# ~/.get_vault_pass.sh
aws secretsmanager get-secret-value \
--secret-id ansible/vault-password \
--query SecretString \
--output textchmod +x ~/.get_vault_pass.sh
ansible-playbook site.yml --vault-password-file ~/.get_vault_pass.shBonnes Pratiques : Organiser les Variables Vault
Le modele le plus maintenable separe vos fichiers de variables en deux fichiers paralleles par groupe :
group_vars/
all/
vars.yml # variables simples + references aux variables vault_
vault.yml # chiffre, uniquement variables prefixees vault_
production/
vars.yml
vault.yml
staging/
vars.yml
vault.ymlgroup_vars/all/vars.yml — texte clair, sur a inspecter dans git :
# group_vars/all/vars.yml
db_host: "db.internal.example.com"
db_port: 5432
db_name: "myapp_prod"
db_password: "{{ vault_db_password }}" # reference, pas la valeur
api_endpoint: "https://api.stripe.com/v1"
stripe_key: "{{ vault_stripe_key }}"
smtp_host: "smtp.sendgrid.net"
smtp_user: "apikey"
smtp_password: "{{ vault_smtp_password }}"group_vars/all/vault.yml — chiffre, toutes avec le prefixe vault_ :
# group_vars/all/vault.yml (ce fichier est chiffre sur disque)
vault_db_password: "Tr0ub4dor&3"
vault_stripe_key: "sk_live_abc123"
vault_smtp_password: "SG.abc123xyz"Avantages de ce modele :
- Les playbooks referencent des noms lisibles (
db_password), pas des variables vault directement git diffmontre les changements dans la structure devars.ymlsans necessite le mot de passe vault- Vous pouvez auditer les variables existant dans le fichier vault par nom (executez
ansible-vault view) - Les nouveaux membres de l’equipe peuvent lire
vars.ymlpour comprendre la structure des variables sans acces vault
Rotation des Mots de Passe Vault avec rekey
La rotation du mot de passe vault est une operation a une seule commande :
ansible-vault rekey group_vars/all/vault.ymlLe mot de passe vault actuel vous sera demande, puis vous devrez saisir et confirmer le nouveau. Le fichier est re-chiffre sur place. Aucun secret n’est dechiffre sur disque durant ce processus.
Pour plusieurs fichiers vault a la fois :
# Re-chiffrer tous les fichiers vault du projet
find . -name "vault.yml" -exec ansible-vault rekey {} \;
# Ou avec --new-vault-password-file pour une rotation non interactive
ansible-vault rekey \
--vault-password-file ~/.old_vault_pass \
--new-vault-password-file ~/.new_vault_pass \
group_vars/all/vault.yml group_vars/production/vault.ymlApres le rekey, mettez a jour le gestionnaire de secrets de votre CI/CD avec le nouveau mot de passe avant la prochaine execution du pipeline.
Utiliser Ansible Vault avec AWX et Semaphore
AWX / Ansible Tower
AWX dispose d’un type de credential natif pour Ansible Vault. Creez un credential de type Vault (Parametres → Credentials → Ajouter → Vault), entrez le mot de passe du vault, et attribuez-le a votre template de job. AWX gere le passage du mot de passe de maniere securisee sans l’exposer dans la sortie du job.
Pour plusieurs vault IDs dans AWX, creez un credential Vault par ID et attribuez-les tous au template de job.
Semaphore UI
Semaphore stocke les mots de passe vault dans son Key Store. Naviguez vers Key Store → Nouvelle Cle, selectionnez le type Mot de passe, entrez votre mot de passe vault, et nommez-le (ex. vault-production). Lors de la creation d’un template de tache, selectionnez la cle vault dans le champ Vault Password.
Semaphore passe la cle a Ansible via un fichier temporaire supprime apres l’execution du playbook, suivant le meme modele de securite que l’approche par fichier de mot de passe en CI/CD.
Comparaison : Ansible Vault vs Alternatives
| Outil | Chiffrement | Natif git | CI/CD | Secrets dynamiques | Complexite |
|---|---|---|---|---|---|
| Ansible Vault | AES-256 | Oui — fichiers dans le repo | Fichier de mot de passe | Via script | Faible |
| HashiCorp Vault | AES-256-GCM | Non — service externe | API + token | Oui (leases) | Elevee |
| SOPS | AES-256 / PGP / KMS | Oui — valeurs chiffrees | Cle KMS | Non | Moyenne |
| git-crypt | AES-256 | Oui — transparent | Cle GPG | Non | Moyenne |
Choisissez Ansible Vault quand vos secrets ne doivent etre accessibles que par les playbooks Ansible et que vous voulez zero infrastructure supplementaire. Choisissez HashiCorp Vault quand vous avez besoin de secrets dynamiques, d’expiration fine des baux ou d’acces aux secrets pour plusieurs applications. SOPS est utile quand vous avez besoin de fichiers chiffres lisibles par des outils autres qu’Ansible (Terraform, Helm). git-crypt fonctionne bien pour les fichiers chiffres generaux dans un repo mais manque d’integrations specifiques a Ansible.
Scenario Reel : Credentials BD et Cles API sur Plusieurs Environnements
Vous gerez trois environnements (developpement, staging, production) pour une application web. Chaque environnement dispose d’une base de donnees PostgreSQL, d’une cle API Stripe et d’un mot de passe SMTP SendGrid. Le developpement utilise des mots de passe locaux faibles ; la production utilise des credentials forts geres par l’equipe securite.
Structure des repertoires :
projet/
ansible.cfg
inventory/
development/hosts
staging/hosts
production/hosts
group_vars/
all/
vars.yml # structure de variables partagee
development/
vars.yml # config dev non sensible
vault.yml # secrets dev chiffres (mot de passe separe)
staging/
vars.yml
vault.yml # secrets staging chiffres
production/
vars.yml
vault.yml # secrets production chiffres (plus restreints)
playbooks/
deploy.yml
db_setup.ymlLe vault.yml de chaque environnement utilise un vault ID et un mot de passe separes, geres par l’equipe appropriee :
# Creer le vault de developpement (mot de passe equipe dev)
ansible-vault create --vault-id dev@prompt group_vars/development/vault.yml
# Creer le vault de staging (mot de passe equipe QA)
ansible-vault create --vault-id staging@prompt group_vars/staging/vault.yml
# Creer le vault de production (mot de passe equipe ops)
ansible-vault create --vault-id prod@prompt group_vars/production/vault.ymlPipeline de deploiement (production uniquement) :
ansible-playbook -i inventory/production playbooks/deploy.yml \
--vault-id prod@~/.vault_prodLe mot de passe du vault de production n’est jamais partage avec les developpeurs ou le QA. Si le vault de staging est compromis, les secrets de production ne sont pas affectes car ils utilisent un mot de passe completement separe.
Pieges et Cas Particuliers
Oublier le mot de passe vault est definitif. Il n’y a pas de mecanisme de recuperation. Les donnees chiffrees sont perdues. Stockez les mots de passe vault dans un gestionnaire de mots de passe et dans un secret CI/CD immediatement apres la creation.
Evitez --ask-vault-pass en automatisation. Cela bloque les pipelines et necessite une entree interactive. Utilisez toujours --vault-password-file dans tout contexte non interactif.
ansible.cfg peut definir des valeurs par defaut vault. Ajoutez vault_password_file = ~/.vault_pass a votre ansible.cfg pour eviter de le specifier a chaque commande.
Les fichiers vault.yml ne doivent jamais etre dans .gitignore. L’objectif est de les commiter chiffres. Si vous etes tente d’ignorer un fichier vault dans git, vous l’avez probablement laisse en texte clair par erreur.
Les fichiers chiffres apparaissent toujours comme modifies dans git lors d’un re-chiffrement identique. AES-256 en mode CBC produit un texte chiffre different pour le meme texte clair a chaque fois. N’executez pas ansible-vault encrypt sur des fichiers inchanges car cela pollue l’historique git.
Les fichiers binaires peuvent aussi etre chiffres. Les certificats SSL, fichiers keystore et cles SSH au format binaire peuvent tous etre chiffres avec ansible-vault encrypt. Ansible les dechiffre dans un fichier temporaire avant de passer le chemin au module concerne.
Depannage
Erreur “Decryption failed” (echec du dechiffrement) :
# Verifier que le mot de passe est correct en visualisant le fichier
ansible-vault view group_vars/all/vault.yml
# Verifier que le vault ID correspond si vous utilisez des vault IDs
ansible-vault view --vault-id prod@prompt group_vars/production/vault.ymlLe playbook s’execute sans demander le mot de passe vault et utilise une valeur incorrecte :
Verifiez si vault_password_file est defini dans ansible.cfg. Si le fichier n’existe pas ou est vide, Ansible ignore silencieusement le dechiffrement vault. Ajoutez temporairement --ask-vault-pass pour confirmer.
Erreur “File is not encrypted” (fichier non chiffre) lors de l’edition :
Le fichier est stocke en texte clair. Chiffrez-le d’abord : ansible-vault encrypt filename.yml.
La variable affiche la chaine litterale {{ vault_db_password }} dans la sortie de la tache :
La variable est referencee mais le fichier vault n’a pas ete charge. Verifiez que le fichier vault se trouve dans un chemin charge automatiquement par Ansible (group_vars/, host_vars/) ou incluez-le explicitement avec vars_files: dans le playbook.
Le pipeline CI/CD affiche le mot de passe vault dans les logs :
Ne passez jamais le mot de passe vault comme argument de ligne de commande. Ecrivez toujours dans un fichier d’abord. Confirmez que votre fournisseur CI masque la variable secrete dans la sortie du log.
Resume
- Stockez tous les secrets dans des fichiers
group_vars/*/vault.ymlchiffres avecansible-vault create - Utilisez la convention de prefixe
vault_pour distinguer les variables chiffrees des simples - Referencez les variables vault depuis des fichiers
vars.ymlsimples en utilisant{{ vault_varname }}pour que les playbooks restent lisibles - Utilisez
encrypt_stringuniquement pour des secrets individuels inline, pas comme schema principal de secrets - Utilisez les vault IDs pour maintenir des mots de passe separes pour differents environnements ou equipes
- Integrez avec CI/CD en utilisant
--vault-password-fileet stockez le mot de passe dans votre gestionnaire de secrets - Faites la rotation des mots de passe vault avec
ansible-vault rekeyet mettez a jour les secrets CI/CD immediatement - Ne stockez jamais les mots de passe vault dans des fichiers commites dans git
- AWX et Semaphore ont un support natif des credentials vault — preferez-le aux solutions alternatives