Using and Rotating Vault Passwords

This chapter consolidates the previous two into one clear picture of which password-supplying method fits which situation, then covers password rotation — and a distinction genuinely worth getting right.

The Three Ways To Supply A Vault Password, Side By Side

Choosing The Right One For The Situation

For occasional, manual work at your own terminal, --ask-vault-pass is simplest and entirely sufficient. For anything automated — a CI pipeline, a scheduled run with nobody present — --vault-password-file, pointed at a securely-stored file or a script that fetches from a real secrets manager, is required, since there’s no human available to type anything. The moment a project genuinely needs separate secrets protected by separate passwords — dev versus prod being the clearest example — --vault-id is the right tool, not a workaround.

ansible-vault rekey: Changing A Password Without Changing The Secret

ansible-vault rekey secrets.yaml

Prompts for the current password to decrypt, then a new password to re-encrypt with. The underlying secret value inside the file — the actual database password, the actual API key — is completely unchanged. Only the password protecting access to that file has changed.

Why Rotate At All?

Standard security practice: periodically changing a password limits how long a leaked or compromised one remains useful to whoever obtained it. It’s also genuinely necessary the moment someone who knew the vault password leaves the team — their knowledge of the old password becomes worthless for this file the instant it’s rekeyed, assuming they don’t separately still hold a copy of something already decrypted.

A Realistic Rotation Scenario

ansible-vault rekey secrets.yaml
# prompts for the current (old) password, then a new one

Distribute the new password only to remaining team members. The departed member’s knowledge of the old password is now useless for this specific file going forward — with one important caveat, covered directly next.

A Gotcha: Rekeying Doesn’t Help If The Secret Itself Was Ever Exposed

This is a crucial distinction, easy to miss. Rekeying changes who can access the encrypted file going forward — it does not change the underlying secret’s actual value. If that value was ever exposed some other way — the classic decrypt-and-forget-to-re-encrypt mistake from earlier in this section, or simply because a now-departed team member used the secret while they had legitimate access and could have noted it down separately — rekeying the vault file does nothing to undo that exposure.

The actual secret itself — the real database password, the real API key — would need to be changed at its true source, not just re-encrypted inside the Ansible file that happens to reference it. Rotating the vault password and rotating the secret itself are two completely different operations, addressing two completely different risks — treating them as interchangeable creates a false sense of security exactly when it matters most.

Best Practices

• Use --ask-vault-pass for manual work, --vault-password-file for automation, --vault-id for genuinely distinct secret scopes — match the method to the actual situation, not out of habit.
• Rekey whenever someone with vault access leaves the team, or on a regular rotation schedule as routine security hygiene.
• Remember rekeying only changes who can decrypt the file. If the underlying secret value was ever actually exposed, it needs to be changed at its real source too — completely separately from any Vault operation.