Quand j’ai commencé à automatiser des infrastructures avec Ansible, j’ai rapidement réalisé qu’un problème revenait sans cesse : comment protéger les mots de passe, clés API et certificats stockés dans les fichiers de configuration ? Laisser un mot de passe en clair dans un playbook, c’est l’équivalent de coller le code de l’alarme sur la porte d’entrée. C’est exactement le problème que résout ansible vault, l’outil de chiffrement intégré nativement à Ansible.

Dans ce guide, je vous montre pas à pas comment utiliser ansible-vault pour sécuriser vos données sensibles. Que vous prépariez votre portfolio BTS SIO SISR ou que vous travailliez sur des projets d’infrastructure en entreprise, maîtriser le chiffrement de vos secrets est une compétence indispensable en 2026.

Qu’est-ce que Ansible Vault

Ansible Vault est une fonctionnalité intégrée à Ansible qui permet de chiffrer et déchiffrer des données sensibles. Contrairement à des solutions externes comme HashiCorp Vault (à ne pas confondre), ansible vault fait partie du paquet Ansible de base. Vous n’avez rien à installer en supplément.

Le principe est simple : vous chiffrez un fichier ou une variable avec un mot de passe maître. Seules les personnes disposant de ce mot de passe peuvent lire ou modifier le contenu. Le chiffrement repose sur l’algorithme AES-256 en mode CTR avec HMAC-SHA256, ce qui garantit à la fois la confidentialité et l’intégrité des données. Selon la documentation officielle d’Ansible, cet algorithme est considéré comme sûr pour un usage en production.

Concrètement, ansible vault peut chiffrer :

• Des fichiers de variables entiers (group_vars, host_vars)
• Des variables individuelles au sein d’un fichier YAML (depuis Ansible 2.3)
• Des fichiers de tâches, des templates, ou tout fichier utilisé par Ansible

Un fichier chiffré par ansible vault commence toujours par l’en-tête $ANSIBLE_VAULT;1.1;AES256, suivi du contenu chiffré en hexadécimal. Cette signature permet à Ansible de détecter automatiquement qu’un fichier nécessite un déchiffrement avant utilisation.

Installer et configurer ansible-vault

La bonne nouvelle, c’est que si vous avez déjà Ansible installé, ansible-vault est déjà disponible sur votre machine. La commande ansible-vault est livrée avec le paquet principal. Si vous partez de zéro, voici comment procéder pour l’installation.

Sur une distribution Debian ou Ubuntu :

sudo apt update
sudo apt install ansible -y
ansible-vault --version

Sur CentOS ou Rocky Linux :

sudo dnf install epel-release -y
sudo dnf install ansible -y

Via pip (méthode recommandée pour obtenir la dernière version) :

pip install ansible
ansible-vault --version

Une fois installé, je vous conseille de configurer le fichier ansible.cfg pour définir un emplacement par défaut pour votre fichier de mot de passe :

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

Cette configuration évite de taper --ask-vault-pass à chaque exécution. Bien entendu, le fichier vault_pass.txt doit avoir des permissions restrictives (chmod 600) et ne doit jamais être versionné dans Git. J’insiste sur ce point auprès de mes étudiants en DevOps : un mot de passe vault commité, même accidentellement, compromet l’ensemble de la chaîne de sécurité.

Créer et chiffrer des fichiers avec ansible vault create

La commande la plus fondamentale est ansible-vault create. Elle crée un nouveau fichier directement chiffré. Votre éditeur de texte s’ouvre, vous saisissez le contenu, et à la sauvegarde, le fichier est automatiquement chiffré.

ansible-vault create group_vars/production/secrets.yml

Ansible vous demande alors de définir un mot de passe (deux fois pour confirmation). L’éditeur s’ouvre et vous pouvez y écrire vos variables sensibles :

db_password: "S3cur3P@ssw0rd!"
api_key: "sk-abc123def456ghi789"
smtp_password: "mailP@ss2026"

Pour chiffrer un fichier existant, utilisez la sous-commande encrypt :

ansible-vault encrypt vars/credentials.yml

Le fichier est remplacé par sa version chiffrée. Si vous l’ouvrez avec un éditeur classique, vous verrez quelque chose comme :

$ANSIBLE_VAULT;1.1;AES256
36326535303237623731636262643038393964613131...
65393035656166303562396230326663613262613036...

Pour chiffrer une variable individuelle plutôt qu’un fichier entier, utilisez encrypt_string. C’est particulièrement utile quand vous voulez garder certaines variables lisibles tout en protégeant les données sensibles :

ansible-vault encrypt_string 'MonMotDePasse' --name 'db_password'

Le résultat peut être directement collé dans un fichier YAML :

db_password: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  61626364656667686970...

Cette approche granulaire est celle que je recommande dans la plupart des cas. Elle permet aux membres de l’équipe de comprendre la structure des variables sans avoir accès aux valeurs sensibles. Quand vous travaillez avec des fichiers de configuration distribués via le module Ansible Copy ou Ansible Template, le chiffrement par variable offre un excellent compromis entre sécurité et lisibilité.

Déchiffrer et modifier des secrets

La commande ansible vault decrypt convertit un fichier chiffré en texte clair. C’est l’opération inverse du chiffrement :

ansible-vault decrypt group_vars/production/secrets.yml

Attention : cette commande remplace le fichier chiffré par sa version en clair. Je déconseille fortement de l’utiliser en production. Si vous avez besoin de consulter le contenu sans modifier le fichier, utilisez plutôt view :

ansible-vault view group_vars/production/secrets.yml

Cette commande affiche le contenu déchiffré dans le terminal sans modifier le fichier sur le disque. C’est la méthode sûre pour vérifier une valeur.

Pour modifier un fichier chiffré, la commande edit est votre meilleure alliée :

ansible-vault edit group_vars/production/secrets.yml

L’éditeur s’ouvre avec le contenu déchiffré. À la sauvegarde, le fichier est automatiquement re-chiffré. C’est le workflow le plus sûr car le fichier ne reste jamais en clair sur le disque.

Si vous devez changer le mot de passe de chiffrement (rotation de secrets, départ d’un collaborateur), utilisez rekey :

ansible-vault rekey group_vars/production/secrets.yml
# Ancien mot de passe, puis nouveau mot de passe

Vous pouvez même utiliser rekey sur plusieurs fichiers simultanément :

ansible-vault rekey group_vars/production/*.yml

Utiliser Vault dans les playbooks et rôles

L’intérêt principal d’ansible vault réside dans son intégration transparente avec les playbooks. Quand vous exécutez un playbook qui référence des variables chiffrées, il suffit de fournir le mot de passe vault pour que tout fonctionne.

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

Ou avec un fichier de mot de passe :

ansible-playbook deploy.yml --vault-password-file ~/.ansible/vault_pass.txt

Voici un exemple concret de playbook utilisant des variables chiffrées pour déployer une base de données :

---
- name: Déployer la base de données PostgreSQL
  hosts: db_servers
  vars_files:
    - vars/main.yml
    - vars/secrets.yml  # fichier chiffré avec vault
  tasks:
    - name: Configurer l'utilisateur PostgreSQL
      postgresql_user:
        name: "{{ db_user }}"
        password: "{{ db_password }}"  # variable chiffrée
        state: present

    - name: Déployer le fichier de configuration
      template:
        src: pg_hba.conf.j2
        dest: /etc/postgresql/14/main/pg_hba.conf
      notify: restart postgresql

Dans cet exemple, le fichier vars/main.yml contient les variables non sensibles (noms de bases, ports) tandis que vars/secrets.yml est chiffré et contient les mots de passe. Ansible déchiffre automatiquement le fichier au moment de l’exécution.

Pour les rôles Ansible, je recommande cette structure de répertoires :

roles/
  database/
    defaults/
      main.yml          # valeurs par défaut (non sensibles)
    vars/
      main.yml          # variables du rôle
      vault.yml          # variables chiffrées
    tasks/
      main.yml
    templates/
      config.j2

Cette organisation sépare clairement les données publiques des données sensibles. C’est un pattern que j’enseigne systématiquement car il facilite la revue de code et le travail collaboratif. Les secrets restent protégés tandis que la logique du rôle reste lisible par tous les membres de l’équipe.

Gestion avancée : multi-vault et password-file

Depuis Ansible 2.4, la fonctionnalité multi-vault permet d’utiliser plusieurs mots de passe différents dans un même projet. C’est essentiel quand vous gérez des environnements avec des niveaux de sécurité distincts.

Le concept repose sur les vault IDs. Chaque mot de passe est associé à un identifiant :

ansible-vault create --vault-id dev@prompt group_vars/dev/secrets.yml
ansible-vault create --vault-id prod@prompt group_vars/prod/secrets.yml

Lors de l’exécution du playbook, vous spécifiez les vault IDs nécessaires :

ansible-playbook deploy.yml \
  --vault-id dev@~/.ansible/dev_pass.txt \
  --vault-id prod@~/.ansible/prod_pass.txt

L’option ansible vault password-file accepte également un script exécutable. C’est particulièrement utile pour récupérer le mot de passe depuis un gestionnaire de secrets externe :

#!/bin/bash
# vault_pass_script.sh
# Récupère le mot de passe depuis AWS Secrets Manager
aws secretsmanager get-secret-value \
  --secret-id ansible-vault-password \
  --query SecretString \
  --output text

ansible-playbook deploy.yml --vault-password-file ./vault_pass_script.sh

Cette approche est celle que je privilégie en environnement professionnel. Le mot de passe vault n’est jamais stocké en clair sur le disque ; il est récupéré dynamiquement depuis un service sécurisé. C’est un niveau de sécurité supérieur que les équipes DevOps adoptent de plus en plus. Selon les recommandations de la ANSSI (Agence nationale de la sécurité des systèmes d’information), le stockage des secrets doit suivre le principe du moindre privilège, et cette méthode s’y conforme parfaitement.

Comparatif des méthodes de chiffrement Ansible

Plusieurs approches existent pour gérer les secrets dans un projet Ansible. Voici un comparatif pour vous aider à choisir la méthode la plus adaptée à votre contexte.

Mon conseil : pour un projet en BTS SIO ou en formation, le chiffrement de fichier entier suffit largement. Pour un environnement de production avec une équipe, combinez vault + password-file avec un script qui interroge un gestionnaire de secrets comme AWS Secrets Manager, Azure Key Vault ou HashiCorp Vault.

Le tableau montre clairement que les variables d’environnement seules ne sont pas une solution acceptable en production. Elles apparaissent dans les logs, les dumps de processus et les fichiers /proc. Ansible Vault offre un niveau de protection bien supérieur car les données sont chiffrées au repos, pas seulement masquées.

Bonnes pratiques de sécurité avec Ansible Vault

Après plusieurs années à former des étudiants et à auditer des projets Ansible en entreprise, voici les bonnes pratiques que je considère comme essentielles.

Organiser ses fichiers vault

Adoptez une convention de nommage claire. Je recommande de nommer les fichiers chiffrés vault.yml et de les placer dans le même répertoire que les variables non chiffrées :

group_vars/
  all/
    vars.yml        # variables publiques
    vault.yml       # variables chiffrées
  production/
    vars.yml
    vault.yml
  staging/
    vars.yml
    vault.yml

Pour éviter toute confusion, préfixez les variables chiffrées avec vault_ et référencez-les dans le fichier non chiffré :

# vars.yml (lisible par tous)
db_password: "{{ vault_db_password }}"

# vault.yml (chiffré)
vault_db_password: "S3cur3P@ss!"

Ce pattern d’indirection est recommandé par la communauté Ansible car il permet de voir d’un coup d’œil quelles variables sont sensibles sans avoir à déchiffrer quoi que ce soit.

Protéger le mot de passe vault

• Ajoutez vault_pass.txt à votre .gitignore systématiquement
• Définissez les permissions à 600 sur le fichier de mot de passe
• Effectuez une rotation régulière du mot de passe avec ansible-vault rekey
• Utilisez un mot de passe différent par environnement grâce aux vault IDs
• Ne partagez jamais le mot de passe par email ou messagerie non chiffrée

Configurer Git correctement

Ajoutez un filtre Git diff pour pouvoir comparer les fichiers vault dans vos diffs :

# .gitattributes
*.vault.yml diff=ansible-vault

# .gitconfig
[diff "ansible-vault"]
  textconv = ansible-vault view

Cette configuration permet à git diff d’afficher les changements en clair dans les fichiers vault, ce qui facilite grandement la revue de code. Pensez aussi à configurer un hook pre-commit pour vérifier qu’aucun fichier sensible n’est commité en clair. La sécurité informatique en entreprise est un enjeu majeur, comme le rappellent les spécialistes en sécurité informatique à Paris.

Auditer et surveiller

Tenez un registre des accès au mot de passe vault. Quand un membre de l’équipe quitte le projet, effectuez immédiatement un rekey sur tous les fichiers vault auxquels il avait accès. C’est un reflexe de sécurité fondamental que beaucoup d’équipes négligent.

Intégration CI/CD et travail en équipe

L’utilisation d’ansible vault dans un pipeline CI/CD nécessite une approche spécifique puisqu’il n’y a personne pour taper le mot de passe interactivement. Voici les méthodes que j’utilise en production.

GitLab CI

Stockez le mot de passe vault dans une variable CI/CD protégée de GitLab :

# .gitlab-ci.yml
deploy_production:
  stage: deploy
  script:
    - echo "$VAULT_PASSWORD" > /tmp/vault_pass.txt
    - chmod 600 /tmp/vault_pass.txt
    - ansible-playbook deploy.yml --vault-password-file /tmp/vault_pass.txt
    - rm -f /tmp/vault_pass.txt
  only:
    - main

GitHub Actions

- name: Déployer avec Ansible
  env:
    VAULT_PASSWORD: ${{ secrets.ANSIBLE_VAULT_PASSWORD }}
  run: |
    echo "$VAULT_PASSWORD" > /tmp/vault_pass.txt
    chmod 600 /tmp/vault_pass.txt
    ansible-playbook deploy.yml --vault-password-file /tmp/vault_pass.txt
    rm -f /tmp/vault_pass.txt

Dans les deux cas, le mot de passe est injecté via une variable secrète de la plateforme CI/CD. Il n’apparaît ni dans les logs ni dans le code source. C’est la méthode standard adoptée par la majorité des équipes professionnelles.

Travail en équipe

Quand plusieurs développeurs travaillent sur le même projet, la gestion du mot de passe vault peut devenir complexe. Voici l’approche que je recommande :

1. Gestionnaire de mots de passe partagé : utilisez un outil comme Bitwarden ou 1Password pour stocker le mot de passe vault de l’équipe
2. Un vault ID par niveau d’accès : les développeurs ont accès au vault « dev », seuls les ops accèdent au vault « prod »
3. Documentation interne : documentez la procédure pour récupérer et utiliser le mot de passe vault dans le README du projet
4. Rotation planifiée : changez le mot de passe vault tous les trimestres ou à chaque départ d’un membre

Pour les projets gérés via Ansible Tower (ou AWX), la gestion des credentials vault est intégrée à l’interface graphique. Tower stocke les mots de passe vault de manière sécurisée et les injecte automatiquement lors de l’exécution des playbooks. C’est un gain de temps considérable pour les équipes qui gèrent de nombreux environnements.

La gestion de la sécurité dans les pipelines d’automatisation est aussi une compétence recherchée dans les alternances en développement informatique. Maîtriser ansible vault vous donnera un avantage concret lors de vos entretiens.

Lucie Moreau

Formatrice IT indépendante depuis 2016, ancienne étudiante BTS SIO SLAM. 6 ans d'expérience en entreprise.