encrypt_string vs fichier complet : chiffrer une seule variable Ansible

ansible-vault encrypt_string chiffre une seule valeur que l’on colle directement dans un fichier YAML clair, à côté d’autres variables non sensibles. Cette page compare ce mode inline avec le chiffrement de fichier complet vu dans la page précédente, explique quand utiliser lequel, et démontre comment garder des diffs Git lisibles sur les variables publiques tout en protégeant les secrets.

À la fin, vous saurez choisir entre les deux patterns selon le contexte (fichier d’inventaire, group_vars/, rôle, playbook), et comprendre pourquoi encrypt_string est devenu le pattern préféré en 2026 dans la majorité des cas.

Pressé ? encrypt_string vs encrypt — la règle

# encrypt_string : 1 variable inline (pattern préféré 2026)
ansible-vault encrypt_string \
  --vault-password-file .vault_password \
  --name 'db_password' \
  's3cur3-passw0rd'

# Sortie à coller dans group_vars/all.yml :
# db_password: !vault |
#       $ANSIBLE_VAULT;1.1;AES256
#       33623037333362623432636361663137...

# encrypt : tout le fichier chiffré
ansible-vault encrypt --vault-password-file .vault_password group_vars/all/vault.yml

Critère de choix :

Situation	Module	Pourquoi
1-3 secrets dans un fichier de 50 variables	encrypt_string	Diffs Git lisibles sur les 47 variables claires
Fichier dédié uniquement aux secrets (vault.yml)	encrypt	Tout est sensible, autant chiffrer en bloc
Variables publiques + secrets mélangés	encrypt_string	Évite que la revue de code se fasse “à l’aveugle”
Migration depuis un fichier en clair	encrypt	Plus rapide, pattern minimal

Glissez pour voir

Sécurité non négociable :

• Pattern préféré 2026 : encrypt_string dans group_vars/<group>/vars.yml (avec quelques variables chiffrées inline) plutôt qu’un fichier vault.yml séparé.
• Préfixe vault_* sur la variable chiffrée (vault_db_password) puis indirection dans defaults/main.yml du rôle (db_password: "{{ vault_db_password }}") — convention claire.
• no_log: true sur les tâches qui consomment un secret — sinon -v leak.
• Grep avant commit : git diff --cached | grep -E "password|secret|token" | grep -v ANSIBLE_VAULT — détecte un secret en clair oublié.

Ce que vous allez apprendre

• Différence concrète entre encrypt (fichier complet) et encrypt_string (variable inline).
• Syntaxe !vault | $ANSIBLE_VAULT;1.1;AES256... pour la valeur chiffrée inline.
• Quand préférer l’un ou l’autre selon le ratio variables claires / sensibles.
• Limites : encrypt_string rechiffré change à chaque édition (diff bruyant si mal géré).
• Combiner les deux dans le même fichier group_vars/all.yml.

Prérequis

• Avoir lu Introduction à Ansible Vault.
• Comprendre group_vars/ et host_vars/ (voir Inventaires).

Recommandation rapide

Situation	Pattern recommandé	Pourquoi
Fichier secret.yml ne contenant que des secrets	Fichier complet chiffré (encrypt)	Tout est sensible, pas besoin de mixer.
group_vars/all.yml mélangeant config publique + 1-2 secrets	encrypt_string inline	Diffs Git lisibles sur les variables publiques.
Inventaire hosts.yml avec un mot de passe par hôte	encrypt_string inline	Hostnames, IPs et groupes restent diffables.
Rôle Ansible defaults/main.yml + vars/main.yml	Fichier vars/main.yml complet chiffré	Pattern d’indirection (voir page dédiée).
Plus de 5 secrets dans un fichier de 20 variables	Séparer : main.yml (clair) + vault.yml (chiffré)	Lisibilité, rotation indépendante.

Glissez pour voir

Règle pratique : si plus de 50 % du fichier est sensible, chiffrer le fichier complet ; sinon, encrypt_string ligne par ligne, ou séparer en deux fichiers.

Critères de comparaison

Cinq critères distinguent les deux approches.

Lisibilité du fichier

Avec fichier complet chiffré, le contenu est opaque :

$ANSIBLE_VAULT;1.1;AES256
33623037333362623432636361663137...
6334323564333065346163363463316...

Avec encrypt_string, les variables publiques restent lisibles, seule la valeur sensible est chiffrée :

inventory/group_vars/all.yml

admin_username: lab78_admin       # ← lisible
http_port: 80                     # ← lisible
admin_password: !vault |          # ← chiffré inline
  $ANSIBLE_VAULT;1.1;AES256
  3937333564633630373064393636643...
  6336323033666336323535663064656...

Lecture en revue de code : la deuxième version est immédiatement compréhensible sans déchiffrer. La première exige ansible-vault view.

Diff Git

C’est le critère décisif dans la plupart des projets.

• Fichier complet chiffré : un changement d’une seule variable rechiffre tout, le diff Git affiche des centaines de lignes hex aléatoires. Impossible à reviewer.
• encrypt_string : modifier http_port: 80 → http_port: 8080 produit un diff Git d’une ligne. Modifier admin_password produit un diff localisé sur les lignes du blob !vault |.

En revue de code, la deuxième version permet de comprendre l’intention d’un changement sans demander le mot de passe vault.

Édition

Action	Fichier complet	encrypt_string
Lire les variables publiques	view requis	Direct (cat)
Modifier une variable publique	edit requis	Édition normale, pas de mot de passe
Modifier un secret	edit (édite tout)	Régénérer le `!vault
Ajouter une variable publique	edit	Direct

Glissez pour voir

encrypt_string est plus pratique au quotidien car les modifications sur les variables publiques (90 % des cas) ne nécessitent jamais de connaître le mot de passe vault.

Périmètre du mot de passe vault

Avec un fichier complet : pour modifier la moindre variable publique, il faut le mot de passe vault. Cela élargit inutilement le périmètre de qui doit le connaître.

Avec encrypt_string : seules les modifications directes du secret demandent le mot de passe. Un développeur peut ajouter worker_count: 4 sans aucun privilège vault.

Performance

Sur un projet avec dizaines de fichiers, le déchiffrement complet de chaque fichier au démarrage du playbook ajoute du temps. encrypt_string ne déchiffre que les valeurs sensibles au moment où Ansible les lit. Différence imperceptible sur 10 fichiers, plus visible sur 200+.

Comparatif détaillé

encrypt — fichier complet

Syntaxe :

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

Résultat : fichier.yml est intégralement remplacé par un blob chiffré.

Cas d’usage idéal : fichier secret.yml ne contenant que des secrets, dédié à vars_files: [secret.yml]. Tout le contenu est sensible, donc le chiffrement intégral n’enlève aucune lisibilité utile.

encrypt_string — variable inline

Syntaxe :

ansible-vault encrypt_string \
  --vault-password-file=.vault_password \
  'SuperSecret2026!' \
  --name 'admin_password'

Sortie :

admin_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          39373335366336323033666336323535663...
          63336232303336363663326632663264363...

On copie-colle ce bloc dans un fichier YAML clair, à côté d’autres variables non sensibles.

Tag !vault : indique à Ansible que la valeur est chiffrée. Le | (literal block) préserve les sauts de ligne du blob hex.

Indentation critique

Le bloc !vault | doit avoir la même indentation que les autres valeurs YAML du fichier. Une mauvaise indentation entraîne un parsing YAML cassé. Si vous éditez à la main, vérifiez avec ansible-inventory --list ou yq que le YAML reste valide.

Étape par étape — chiffrer une variable inline

1. Préparer le fichier YAML clair :

   inventory/group_vars/all.yml

   admin_username: lab78_admin
   http_port: 80

2. Générer la variable chiffrée :

   ansible-vault encrypt_string \
     --vault-password-file=.vault_password \
     'AdminLab78SecretPass!' \
     --name 'admin_password'

3. Coller la sortie dans group_vars/all.yml :

   inventory/group_vars/all.yml

   admin_username: lab78_admin
   http_port: 80
   admin_password: !vault |
             $ANSIBLE_VAULT;1.1;AES256
             393733353636633...
             633362323033363...

4. Tester que le playbook lit la valeur :

   ansible -i inventory/hosts.yml all \
     -m debug -a "var=admin_password" \
     --vault-password-file=.vault_password

   Sortie attendue : la valeur claire AdminLab78SecretPass! (en local, pour debug uniquement).

Quand utiliser quoi — exemples concrets

Cas A — fichier secret.yml dédié

Tout le contenu est sensible : 4 mots de passe, 2 tokens.

# secret.yml (CHIFFRÉ COMPLÈTEMENT)
db_root_password: ...
db_app_password: ...
api_token_internal: ...
api_token_external: ...
smtp_password: ...
ssh_key_passphrase: ...

→ Fichier complet chiffré (ansible-vault encrypt secret.yml). Pas de variable publique, pas de gain à inline.

Cas B — group_vars/webservers/all.yml

Variables de config publiques (port, version, env) avec un seul secret (mot de passe admin).

group_vars/webservers/all.yml

http_port: 80
worker_count: 4
deployment_environment: production
admin_password: !vault |     # ← seule valeur chiffrée
  $ANSIBLE_VAULT;1.1;AES256
  ...

→ encrypt_string sur la seule variable sensible. Diff Git lisible, périmètre vault limité.

Cas C — group_vars/<groupe>/main.yml + vault.yml

5 secrets, 10 variables publiques. Les deux fichiers cohabitent.

group_vars/webservers/
├── main.yml      # 10 variables publiques (clair)
└── vault.yml     # 5 secrets (FICHIER COMPLET CHIFFRÉ)

→ Séparer : pattern industriel détaillé dans la page Playbooks mixtes.

Lab pratique

Le lab vault/chiffrer-fichier-variable du repo ansible-training couvre exactement cette page :

• inventory/group_vars/all.yml mixe admin_username (clair) et admin_password (chiffré inline).
• 4 tests pytest valident que la variable chiffrée est correctement déchiffrée à l’exécution.
• Le challenge ajoute un second secret admin_token dans le même fichier.

Suivre le lab : labs/vault/chiffrer-fichier-variable/README.md.

Pièges courants

• Indentation cassée : copier-coller le !vault | sans aligner les espaces avec le reste du YAML. Ansible parse mal et la variable apparaît undefined.
• Re-chiffrement à chaque modification : éditer un encrypt_string produit un blob hex différent à chaque fois (sel aléatoire), même pour la même valeur. Diff Git “bruyant” si on régénère sans nécessité.
• Mélange dans vars: du playbook : encrypt_string est principalement utilisé dans des fichiers d’inventaire ou de groupe, pas dans la section vars: d’un play. Préférer vars_files: qui Ansible déchiffre automatiquement.
• Oubli du --name : sans --name, la sortie n’est qu’un blob !vault | sans clé, qu’il faut nommer manuellement.

À retenir

• encrypt_string chiffre une seule valeur que l’on colle dans un YAML clair, à côté d’autres variables non sensibles.
• encrypt chiffre tout un fichier. À réserver aux fichiers ne contenant que des secrets.
• Diffs Git lisibles sont la raison principale de préférer encrypt_string dans 80 % des cas.
• Un bloc !vault | doit garder une indentation cohérente avec le reste du YAML.
• Pour plus de 5 secrets dans un fichier mixte, séparer : main.yml clair + vault.yml complet chiffré (page suivante).

Prochaines étapes

Multi-environnements avec vault-id Plusieurs mots de passe vault, un par environnement (dev, prod). Rotation isolée.

Pattern main.yml + vault.yml par groupe Séparer variables publiques et secrets dans des fichiers distincts.

Vault dans les rôles defaults/main.yml + vars/main.yml chiffré : indirection vault_*.

Lab 78 sur GitHub Suivre le lab pas à pas, tests pytest inclus.

×

📖 Voir la documentation →