Premiers pas avec Ansible Vault : chiffrer un fichier de secrets et l'utiliser dans un playbook

Votre premier playbook installait nginx — il est temps de manipuler des secrets. Dès que votre Ansible touche à un mot de passe de base de données, un token API ou une clé privée, vous devez les chiffrer avant qu’ils n’entrent dans Git. Cette page vous fait passer du « j’ai un fichier secret.yml en clair » à « mon fichier est chiffré, mon playbook le déchiffre au runtime, mon repo est commitable », en 7 étapes très progressives. À la fin : un .vault_password sécurisé, un fichier YAML chiffré avec ansible-vault encrypt, consommé via vars_files:, avec no_log: true sur les tâches sensibles.

# 1. Créer un mot de passe vault (32 octets aléatoires, mode 0600)
openssl rand -base64 32 > .vault_password
chmod 0600 .vault_password
echo ".vault_password" >> .gitignore

# 2. Chiffrer le fichier de secrets
ansible-vault encrypt --vault-password-file .vault_password group_vars/all/vault.yml

# 3. Consommer dans un playbook + lancer
ansible-playbook --vault-password-file .vault_password site.yml

Le fichier chiffré commence par $ANSIBLE_VAULT;1.1;AES256 — Ansible détecte l’en-tête et déchiffre automatiquement. La suite explique chaque étape, et comment ne pas se tirer une balle dans le pied au passage (commit du .vault_password, oubli de no_log:).

Ce que vous allez apprendre

Créer un mot de passe vault dans .vault_password avec mode 0600.
Chiffrer un fichier de secrets avec ansible-vault encrypt.
Visualiser et éditer un fichier chiffré sans le déchiffrer manuellement.
Consommer un fichier chiffré depuis un playbook (vars_files:).
Lancer un playbook avec --vault-password-file ou --ask-vault-pass.
Protéger la sortie Ansible avec no_log: true sur les tâches sensibles.

Prérequis

Avoir validé Premier playbook.
Lab homelab avec db1.lab joignable en SSH.
ansible-vault --version retourne une version (livré avec ansible-core).

Pourquoi Ansible Vault dès maintenant

Trois raisons concrètes le rendent incontournable très tôt :

Git garde tout : un mot de passe commit en clair par accident reste dans git log même après un revert. GitHub indexe et propose le contenu via toute la chaîne de fork.
Les .gitignore ne chiffrent pas : un git add -f ou un fichier renommé qui sort du pattern, et le secret part. Le .gitignore est un filtre, pas une protection.
Ansible Vault chiffre AES-256 : même committé sur GitHub public, le contenu reste protégé tant que le mot de passe vault, lui, est correctement isolé.

Vous reconnaissez un fichier chiffré à son en-tête caractéristique :

$ANSIBLE_VAULT;1.1;AES256
33623037333362623432636361663137...

C’est ce préfixe qui permet à Ansible de détecter automatiquement un fichier chiffré : pas besoin de l’annoncer dans le playbook, Ansible voit l’en-tête, demande le mot de passe, déchiffre en mémoire.

Étape 1 — Créer un mot de passe vault

Le pattern recommandé : un fichier .vault_password sur disque, mode 0600, jamais commité.

cd labs/premiers-pas/ansible-vault/

echo "premiers-pas-vault-2026" > .vault_password
chmod 0600 .vault_password
ls -la .vault_password

Pourquoi 0600 ? Mode -rw------- signifie « lecture/écriture uniquement par le propriétaire ». Sans cette restriction, n’importe quel autre user du système (autre admin, runner CI partagé) peut lire le mot de passe. Ansible Vault accepterait quand même le fichier, mais c’est un anti-pattern majeur.

Étape 2 — Créer un fichier de secrets en clair

Démarrez avec un fichier YAML lisible, vous le chiffrerez à l’étape suivante.

db_password: "Sup3rSecretP@ss2026!"
api_token: "tok_demo_abc123xyz789"

Vérifiez :

cat secret.yml

Le contenu apparaît en clair. Pour l’instant, ne le commitez surtout pas.

Étape 3 — Chiffrer le fichier

Une seule commande transforme le fichier en blob chiffré :

ansible-vault encrypt secret.yml --vault-password-file=.vault_password

Sortie :

Encryption successful

Vérifiez le résultat :

head -1 secret.yml

$ANSIBLE_VAULT;1.1;AES256

Le fichier est désormais illisible sans le mot de passe. Vous pouvez le git add et le commiter en toute sécurité.

Étape 4 — Lire le contenu sans le modifier

ansible-vault view secret.yml --vault-password-file=.vault_password

Affiche le YAML déchiffré dans le terminal sans toucher au fichier sur disque. Idéal pour relire rapidement avant un commit ou en revue de code.

Étape 5 — Modifier un fichier chiffré

ansible-vault edit secret.yml --vault-password-file=.vault_password

Cette commande déchiffre en mémoire, ouvre votre $EDITOR (vim, nano, code), vous éditez normalement, et rechiffre à la fermeture. Aucune copie en clair ne touche le disque.

À ne pas faire : view > tmp.yml, modifier tmp.yml, puis encrypt. Cette séquence laisse une fenêtre où le secret existe en clair sur disque — l’éditeur peut faire un swap, un crash peut laisser un fichier orphelin.

Étape 6 — Consommer le secret depuis un playbook

Le pattern le plus simple : vars_files qui pointe sur le fichier chiffré.

- name: Premiers pas vault — déposer un secret sur db1
  hosts: db1.lab
  become: true
  gather_facts: false
  vars_files:
    - secret.yml          # ← Ansible déchiffre automatiquement

  tasks:
    - name: Déposer la config DB avec le mot de passe déchiffré
      ansible.builtin.copy:
        dest: /tmp/db-config.txt
        content: |
          # Lab 04b — vault déchiffrement OK
          db_password={{ db_password }}
          api_token={{ api_token }}
        owner: root
        group: root
        mode: "0600"
      no_log: true

Trois bonnes pratiques visibles dans cette tâche :

vars_files: [secret.yml] charge le fichier (chiffré ou non) — Ansible détecte le header $ANSIBLE_VAULT automatiquement.
mode: "0600" sur le fichier déposé évite que d’autres users du serveur cible puissent le lire.
no_log: true sur la tâche masque la sortie Ansible (sinon ansible-playbook -v afficherait les variables résolues, donc le secret en clair).

Étape 7 — Lancer le playbook

ansible-playbook lab.yml --vault-password-file=.vault_password

Sortie :

PLAY [Premiers pas vault — déposer un secret sur db1] ********

TASK [Déposer la config DB avec le mot de passe déchiffré] ***
changed: [db1.lab]

PLAY RECAP ***************************************************
db1.lab : ok=1 changed=1 unreachable=0 failed=0

Vérification côté cible :

ssh ansible@db1.lab "sudo cat /tmp/db-config.txt"

# Lab 04b — vault déchiffrement OK
db_password=Sup3rSecretP@ss2026!
api_token=tok_demo_abc123xyz789

Le fichier db-config.txt contient les valeurs déchiffrées sur la cible — déchiffrement transparent au runtime, sans jamais écrire le clair sur disque côté contrôleur.

Que se passe-t-il sans le mot de passe ?

ansible-playbook lab.yml         # SANS --vault-password-file

Sortie :

ERROR! Attempting to decrypt but no vault secrets found

Ansible refuse de tourner sans le mot de passe — sécurité par défaut. Pour un workflow interactif (en démo, formation), utilisez :

ansible-playbook lab.yml --ask-vault-pass

Vous serez invité à taper le mot de passe au clavier. Pas pour la CI/CD — un fichier en 0600 ou une variable d’env pointant vers un secret manager est plus pratique et plus sûr.

Lab pratique

Le lab premiers-pas/ansible-vault du repo ansible-training reproduit cette page avec 8 tests pytest automatisés qui valident :

Le fichier .vault_password existe et est en mode 0600.
Le fichier app_secrets.yml est bien chiffré (en-tête $ANSIBLE_VAULT).
Le playbook solution.yml dépose /tmp/db1-app.conf sur db1.lab avec mode 0600, owner root.
Les 3 secrets attendus (db_password=, jwt_secret=, redis_token=) sont présents et non vides.

Suivre : labs/premiers-pas/ansible-vault/README.md.

Sécurité — bonnes pratiques

.vault_password en mode 0600 et gitignored dès la création du projet.
ansible.cfg : poser vault_password_file = .vault_password dans [defaults] pour éviter de répéter --vault-password-file à chaque commande.
no_log: true sur toute tâche command:, shell:, uri:, copy: avec content: qui manipule un secret.
mode: "0600" ou plus restrictif sur tout fichier déposé contenant des valeurs déchiffrées.
Rotation périodique du mot de passe vault (tous les 6 à 12 mois) avec ansible-vault rekey.
Pas de mot de passe en CLI : un ansible-playbook ... --vault-password "MonPass" (s’il existait) apparaîtrait dans ps aux et l’historique shell.

Dépannage

Symptôme	Cause probable	Solution
`Decryption failed`	Mauvais mot de passe ou fichier corrompu	Vérifier `.vault_password`, retenter `ansible-vault view`
`input is not vault encrypted data`	Fichier non chiffré passé à `view`	Vérifier l’en-tête avec `head -1 secret.yml`
`Attempting to decrypt but no vault secrets found`	`--vault-password-file` oublié	Ajouter l’option ou poser `vault_password_file` dans `ansible.cfg`
Variable `undefined` au runtime	`vars_files` mal pointé	Vérifier le chemin relatif au playbook
Secret apparaît dans `-v`	`no_log: true` manquant sur la tâche	Ajouter `no_log: true` sur la task qui manipule le secret

À retenir

Ansible Vault chiffre un fichier YAML avec AES-256 ; en-tête $ANSIBLE_VAULT;1.1;AES256.
.vault_password : mode 0600, gitignored, jamais commité.
5 commandes essentielles : encrypt, view, edit, rekey, decrypt.
Consommation : vars_files: [secret.yml] dans le playbook ; Ansible déchiffre automatiquement au runtime.
no_log: true masque la sortie pour ne pas exposer le secret en mode verbose.
--vault-password-file > --ask-vault-pass en CI/CD ; l’inverse en démo formation.

Prochaines étapes

Section complète Vault & Secrets Multi-vault-id, encrypt_string, intégration HashiCorp Vault et Passbolt — tout le parcours.

encrypt_string : chiffrer une seule variable Pattern préféré 2026 — garder un YAML diffable avec une seule valeur chiffrée.

Vault-id multiples (dev/prod) Mots de passe distincts par environnement, rotation isolée.

Lab 04b sur GitHub Suivre le lab pas à pas avec 8 tests pytest+testinfra automatisés.