Utiliser Ansible Vault au quotidien : vault-id et fichier de mot de passe

En 8.1, on a chiffré nos premières variables avec --ask-vault-pass, tapé à la main à chaque exécution. Pratique pour un lab, vite fatigant en usage réel — surtout si Nordika a besoin de mots de passe différents pour son environnement de développement et sa production. Voyons comment fluidifier tout ça.

Éviter de retaper le mot de passe à chaque fois

Plutôt que --ask-vault-pass, on peut stocker le mot de passe du Vault dans un fichier local, et le pointer à l’exécution :

echo "MonMotDePasseVault123" > ~/.vault_pass.txt
chmod 600 ~/.vault_pass.txt

ansible-playbook playbook_mariadb.yaml -i inventaire.yaml --vault-password-file ~/.vault_pass.txt

⚠️ Ce fichier .vault_pass.txt est lui-même un secret : chmod 600 restreint sa lecture à vous seul, et il ne doit jamais être commité dans Git. On y revient juste après.

`ansible.cfg` : ne plus taper l’option à chaque fois

Pour éviter de répéter --vault-password-file sur chaque commande, on peut le déclarer une bonne fois dans ansible.cfg (évoqué en 1.3) :

# ansible.cfg
[defaults]
vault_password_file = ~/.vault_pass.txt

Désormais, une simple commande suffit :

ansible-playbook playbook_mariadb.yaml -i inventaire.yaml

Plusieurs Vaults pour plusieurs environnements : `vault-id`

Nordika a typiquement besoin de secrets différents pour développement et production — pas question d’utiliser le même mot de passe MariaDB des deux côtés. Ansible permet de nommer plusieurs Vaults distincts avec --vault-id :

ansible-vault encrypt group_vars/dev/databases.yml --vault-id dev@prompt
ansible-vault encrypt group_vars/prod/databases.yml --vault-id prod@prompt

Chaque vault-id (dev, prod) a son propre mot de passe, demandé séparément. À l’exécution, on précise quel(s) Vault(s) déverrouiller :

ansible-playbook playbook_mariadb.yaml -i inventaire/prod --vault-id prod@prompt

Avec des fichiers de mot de passe plutôt qu’un prompt interactif, ça devient :

Cette séparation évite un risque bien réel : un admin qui déchiffrerait accidentellement (ou volontairement, en cas de départ mouvementé) les secrets de production alors qu’il ne devait avoir accès qu’au Vault de dev.

Protéger le fichier de mot de passe dans Git

Le fichier .vault_pass.txt (ou ses variantes dev/prod) ne doit jamais se retrouver dans votre dépôt Git — sinon, tout l’intérêt de Vault s’effondre : n’importe qui avec accès au dépôt pourrait déchiffrer tous vos secrets.

# .gitignore
.vault_pass.txt
.vault_pass_*.txt

Ce fichier doit être transmis autrement : partagé de façon sécurisée entre admins (un gestionnaire de mots de passe d’équipe, par exemple), ou généré directement sur chaque machine autorisée à exécuter les playbooks.

Rejouer le playbook du TP 7 avec Vault

Reprenons l’exemple concret de la section 7 : le mot de passe d’Alice, chiffré en 8.1.

ansible-vault encrypt_string 'MotDePasseAlice123!' --name 'alice_password_clair' --vault-password-file ~/.vault_pass.txt

# host_vars/nrd-web1.yml
alice_password_clair: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          66386439653236336462626566653063336164663966303231363934653561...

- name: Créer le compte avec mot de passe vaulté
  ansible.builtin.user:
    name: alice
    password: "{{ alice_password_clair | password_hash('sha512') }}"

ansible-playbook playbook_onboarding.yaml -i inventaire.yaml

Grâce à ansible.cfg, le fichier de mot de passe est utilisé automatiquement — aucune option supplémentaire à taper, et pourtant le secret reste protégé de bout en bout, de Git jusqu’à l’exécution.

Ce qu’il faut retenir

--vault-password-file (ou son équivalent dans ansible.cfg) évite de retaper le mot de passe à chaque exécution.
--vault-id permet plusieurs Vaults distincts, typiquement un par environnement (dev/prod), chacun avec son propre mot de passe.
Le fichier de mot de passe Vault ne doit jamais être commité — direction .gitignore, sans exception.
Ce mécanisme s’applique à toutes les variables vaultées vues en 8.1, sans rien changer côté playbook.

Dans la prochaine leçon, on termine cette section avec become : l’élévation de privilèges qu’on a utilisée depuis le début sans jamais vraiment s’y arrêter.