Ansible Vault : chiffrer un premier fichier de secrets en 5 minutes

Ansible Vault chiffre vos fichiers sensibles avec AES-256 et un mot de passe que vous gardez hors du dépôt Git. Cette page vous fait passer de zéro à un premier playbook qui consomme un fichier de secrets chiffré, en 5 commandes : encrypt, view, edit, rekey, decrypt. Public visé : tout opérateur Ansible qui n'a jamais utilisé Vault et veut adopter le pattern minimal recommandé en 2026.

À la fin, vous saurez créer un secret.yml chiffré, le versionner sans risque, le modifier sans le déchiffrer manuellement, et le consommer depuis un playbook avec vars_files.

Ce que vous allez apprendre

• Créer un fichier chiffré avec ansible-vault encrypt.
• Lire son contenu sans le modifier (view).
• Modifier un fichier chiffré (edit) sans déchiffrer/rechiffrer manuellement.
• Rotater le mot de passe sans toucher aux données (rekey).
• Consommer un fichier chiffré depuis un playbook avec vars_files.
• Sécuriser le mot de passe lui-même (mode 0600, .gitignore, env var).

Prérequis

• Ansible 2.18+ installé (voir Installation).
• Un cible SSH joignable (lab web1.lab ou équivalent).
• Comprendre les vars_files et vars dans un playbook (voir Premier playbook).

Pourquoi Ansible Vault, vraiment

Trois constats motivent Ansible Vault :

• Un mot de passe en clair dans Git est compromis : Git garde l'historique, un revert ne supprime rien. GitHub indexe et propose ce contenu via git log à toute personne ayant accès en lecture.
• Le .gitignore n'est pas une stratégie de sécurité : c'est juste un filtre. Un git add fichier.yml -f ou un fichier renommé qui sort du pattern, et le secret part.
• Ansible Vault rend le fichier illisible sans le mot de passe : même committé, le contenu reste protégé tant que le mot de passe vault est correctement isolé.

Le format chiffré commence par une ligne d'en-tête caractéristique :

$ANSIBLE_VAULT;1.1;AES256
33623037333362623432636361663137...

C'est ce 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 fichier de mot de passe vault

La pratique recommandée : un fichier de mot de passe sur disque, en mode 0600, jamais commité.

# Générer un mot de passe fort et le poser dans .vault_password
echo "DemoPassword2026!Lab77" > .vault_password
chmod 600 .vault_password

# Bloquer toute possibilité de commit accidentel
echo ".vault_password" >> ../../.gitignore

Pourquoi ce pattern ? Trois raisons :

• Mode 0600 : seul votre user lit/écrit. Un autre utilisateur du serveur (CI runner partagé) ne peut pas le lire.
• Hors du dépôt : impossible à committer accidentellement, et chaque environnement (laptop, CI, prod) en a sa propre copie.
• Rejouable : --vault-password-file=.vault_password dispense de retaper le mot de passe à chaque commande.

En production, on durcit

Le fichier .vault_password au format texte clair convient pour un poste de développement. En CI/CD, on passe le mot de passe via une variable d'env (ANSIBLE_VAULT_PASSWORD_FILE pointant vers un fichier monté en tmpfs), et on récupère la valeur depuis un secret manager (GitHub Secrets, GitLab CI variables, AWS Secrets Manager).

Étape 2, Chiffrer un premier fichier

Créer un fichier YAML simple, puis le chiffrer.

cat > secret.yml <<'EOF'
db_password: "SuperSecretLab77!"
api_token: "tok_lab77_xyz_abc"
EOF

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

Sortie attendue :

Encryption successful

Vérifier 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 3, Lire, modifier, rotater

Quatre commandes couvrent 95 % des cas d'usage quotidiens.

1. Lire le contenu sans modifier le fichier sur disque :

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

   Affiche le YAML déchiffré dans le terminal. Idéal pour relire rapidement.

2. Modifier le fichier, Ansible le déchiffre en $EDITOR, vous éditez, il rechiffre à la fermeture :

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

   Aucune copie en clair ne reste sur disque. Ne jamais view > tmp.yml, éditer, puis encrypt, ce détour laisse une fenêtre où le secret existe en clair.

3. Rotater le mot de passe Vault sans toucher au contenu :

   ansible-vault rekey secret.yml \
     --vault-password-file=.vault_password \
     --new-vault-password-file=.vault_password.new

   Le contenu reste identique, seul le mot de passe de chiffrement change. Pratique en cas de suspicion de fuite du mot de passe ancien.

4. Déchiffrer définitivement (rare, sauf migration) :

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

   Le fichier redevient lisible en clair. À éviter en pratique : si vous voulez juste lire, utilisez view.

Étape 4, Consommer le secret depuis un playbook

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

playbook.yml

- name: Lab 77, premier playbook avec Ansible Vault
  hosts: web1.lab
  become: true
  gather_facts: false

  vars_files:
    - secret.yml          # Ansible déchiffre automatiquement

  tasks:
    - name: Pose un fichier qui prouve que les variables sont accessibles
      ansible.builtin.copy:
        dest: /tmp/lab77-vault-demo.txt
        content: |
          Vault demo, fichier de secrets chiffre
          db_password length: {{ db_password | length }}
          api_token starts: {{ api_token[:8] }}
        mode: "0600"

Lancer le playbook :

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

Sortie attendue :

PLAY [Lab 77, premier playbook avec Ansible Vault] ***
TASK [Pose un fichier...] ***
changed: [web1.lab]

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

Vérification côté cible :

ssh ansible@web1.lab "sudo cat /tmp/lab77-vault-demo.txt"

Le fichier sur web1.lab affiche db_password length: 18 et le préfixe du token, sans jamais avoir exposé la valeur claire dans la sortie Ansible.

Astuce no_log

Pour des tâches qui manipulent un secret avec command: ou shell:, ajoutez no_log: true sur la tâche. Sans ça, Ansible logge la commande complète (avec le secret) en mode debug ou en cas d'erreur.

Mettre en pratique

Les cinq commandes de base ne se retiennent qu'après les avoir enchaînées sur un même fichier. Le lab vous fait chiffrer un fichier de variables, le relire, le modifier sans jamais le laisser en clair sur disque, changer son mot de passe de chiffrement, puis le consommer depuis un playbook avec vars_files. La vérification contrôle l'en-tête $ANSIBLE_VAULT du fichier, l'accès aux variables à l'exécution et l'exclusion du mot de passe du dépôt Git ; le challenge final demande de combiner deux fichiers chiffrés dans un même playbook.

Lab pratique

Ansible Vault : chiffrer un premier fichier de secrets

$ dsoxlab run vault-introduction

Environnement : VM·Durée : ~35 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run vault-introduction
dsoxlab check vault-introduction

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Sécurité, bonnes pratiques

• .vault_password en mode 0600 et dans .gitignore dès la création du dépôt.
• ansible.cfg : poser vault_password_file = .vault_password dans [defaults] pour éviter de répéter --vault-password-file à chaque commande.
• Rotation du mot de passe vault tous les 6 à 12 mois, ou immédiatement en cas de suspicion de fuite (ansible-vault rekey).
• no_log: true sur toute tâche command:, shell:, uri: qui manipule un secret en argument.
• CI/CD : le mot de passe vient d'un secret manager (GitHub Secrets, GitLab CI variables), jamais en dur dans .gitlab-ci.yml.
• Limiter le périmètre : un fichier secret.yml partagé entre 50 projets est un risque, préférer un fichier par projet ou par groupe d'inventaire.

Dépannage

Symptôme	Cause probable	Solution
ERROR! Decryption failed	Mauvais mot de passe ou fichier corrompu	Vérifier .vault_password, retenter view
ERROR! input is not vault encrypted data	Fichier non chiffré passé à view	Vérifier l'en-tête $ANSIBLE_VAULT avec head -1
Variables vault_* non résolues	vars_files oublié dans le playbook	Ajouter vars_files: [secret.yml]
Le playbook demande le mot de passe interactivement	--vault-password-file non passé ou ignoré	Vérifier le chemin, ou poser vault_password_file dans ansible.cfg

Glissez pour voir

À retenir

• Ansible Vault chiffre un fichier YAML avec AES-256 ; l'en-tête commence par $ANSIBLE_VAULT.
• Le mot de passe vit dans .vault_password (mode 0600, .gitignore), jamais dans Git.
• 5 commandes essentielles : encrypt, view, edit, rekey, decrypt.
• Consommation : vars_files: [secret.yml] dans le playbook ; Ansible déchiffre automatiquement.
• no_log: true sur toute tâche manipulant un secret en argument shell.
• Rotation : ansible-vault rekey change le mot de passe sans toucher au contenu.

Pour aller plus loin

• Vault-id multiples (dev/prod) : Un mot de passe par environnement, pour qu'une fuite en dev n'ouvre pas la prod.
• Playbooks mixtes : Le pattern recommandé : variables publiques et secrets séparés dans chaque group_vars.
• HashiCorp Vault / OpenBao : Quand le mot de passe partagé devient ingérable, la récupération dynamique prend le relais.

×

📖 Voir la documentation →