Managing Vault Passwords

--ask-vault-pass, used in every example so far, means typing a password interactively every single time — fine occasionally, genuinely painful for automation, or for anyone running several vault-related commands back to back. This chapter covers the alternatives.

--vault-password-file: Reading The Password From A File

ansible-playbook site.yaml --vault-password-file ~/.vault_pass.txt

Reads the password directly from that file — no interactive prompt at all. This is essential for automation and CI, where there’s genuinely no human present to type anything. The target can also be an executable script rather than a plain file, letting the password come from a real secrets manager instead of a static file on disk.

The Password File Itself Should Never Be Committed

Worth stating explicitly, right after establishing that encrypted content is safe to commit: the password file is not. ~/.vault_pass.txt is itself a plaintext secret — the literal key to everything else — and it must live somewhere entirely outside version control: your home directory, a CI system’s own secret storage, anywhere but the repository itself.

Setting A Default In ansible.cfg

Recall the configuration chapter, all the way back at the start of this course — vault_password_file under [defaults] avoids typing --vault-password-file on every single command:

[defaults]
vault_password_file = ~/.vault_pass.txt

With this set, plain ansible-playbook site.yaml works without any vault-related flag at all — the exact same convenience inventory and private_key_file gave you back in that original chapter, now applied to Vault.

Multiple Vaults, Multiple Passwords: --vault-id

Real projects often need genuinely different passwords protecting different secrets — a “dev” password for development secrets, a completely separate “prod” password for production ones, so someone with only dev access simply cannot decrypt production secrets at all. --vault-id labels a password with an identifier, and that same label is used consistently when encrypting or decrypting:

ansible-vault encrypt_string 'dev-secret' --vault-id dev@prompt --name 'api_key'

dev@prompt means: this value is labeled dev, and its password should be requested interactively. The source can also be a file, exactly like --vault-password-file: dev@~/.vault_pass_dev.txt.

A Realistic Example: Separate Passwords Per Environment

Running a playbook that uses both dev and prod secrets, supplying both passwords at once:

ansible-playbook site.yaml --vault-id dev@~/.vault_pass_dev.txt --vault-id prod@~/.vault_pass_prod.txt

Ansible matches each encrypted value to its correct label and decrypts it with the corresponding password. Give a junior team member only the dev password, and they genuinely cannot decrypt production secrets, even with full read access to the repository itself — a real access-control benefit, not just organizational tidiness.

A Gotcha: A Password File Is Only As Safe As Its Own Permissions

If ~/.vault_pass.txt is readable by anyone on a shared machine — a real possibility depending on default file-creation permissions — any other user on that machine can read it and decrypt everything it protects. Set restrictive permissions explicitly:

chmod 600 ~/.vault_pass.txt

Readable only by its owner — the same permission discipline that matters for any sensitive file, applied here to the one file that unlocks all the others.

Best Practices

• Never commit a vault password file to version control — only the encrypted content itself is ever safe to commit.
• Set vault_password_file in ansible.cfg for a smoother default workflow, exactly as the original configuration chapter established for inventory and private keys.
• Use --vault-id with meaningful labels the moment a project genuinely needs different secrets protected by different passwords or access levels.
• Restrict permissions on any password file (chmod 600), especially on shared or multi-user machines.