Viewing, Editing and Decrypting Encrypted Files

Continuing from the previous chapter, three more commands round out working with an encrypted file day to day — and one of them carries a real, serious risk worth understanding before you ever reach for it.

ansible-vault view: Reading Without Modifying

ansible-vault view secrets.yaml

Prompts for the password, prints the decrypted content to your terminal, and leaves the file on disk completely untouched — genuinely read-only. Good for a quick “what’s actually in this file” check without any risk of accidentally changing it.

ansible-vault edit: The Safe Way To Modify An Encrypted File

ansible-vault edit secrets.yaml

Decrypts the file, opens your editor with the plaintext content, and — critically — re-encrypts it automatically the moment you save and close. The file is never left in a plaintext state on disk at any point during this workflow.

ansible-vault decrypt: Removing Encryption Entirely

ansible-vault decrypt secrets.yaml

This is different in kind, not just in name — it replaces the encrypted file with genuine, permanent plaintext on disk. The file now sits there exactly like any other plain YAML file, unencrypted, until you explicitly re-encrypt it yourself.

The Real Danger: Forgetting To Re-Encrypt

Here’s the mistake this chapter exists to prevent. A tempting but genuinely dangerous workflow:

ansible-vault decrypt secrets.yaml
# (edit the file directly with any text editor)
git add secrets.yaml
git commit -m "Update config"
# — forgot to re-encrypt before committing

The now-plaintext secret gets committed to git, in full, exactly as written. And here’s the part that makes this worse than it might first sound: even if you notice the mistake and immediately re-encrypt the file in a following commit, the plaintext secret is still sitting there in git’s history, in that earlier commit, readable by anyone who can look back through it — forever, unless you do a genuinely invasive history rewrite. A “fix” commit doesn’t undo an exposure that already happened.

A Safer Habit: Prefer edit Over decrypt

ansible-vault edit never creates that risky intermediate state at all — the decrypt-then-re-encrypt cycle happens entirely within one command’s execution, with nothing plaintext ever sitting on disk in between for you to accidentally git add. Default to edit for any modification. Reserve decrypt specifically for the rare, deliberate case where you genuinely want to remove encryption from a file for good — migrating away from Vault entirely for that particular file, say — and even then, treat it with real care.

Best Practices

• Use ansible-vault view for read-only inspection — it never touches the file at all.
• Default to ansible-vault edit for any modification — it never leaves a plaintext version on disk at any point that could be accidentally committed.
• Reserve ansible-vault decrypt for the rare, deliberate case of removing encryption for good, and immediately verify you haven’t left (or committed) the resulting plaintext file.
• If a secret is ever accidentally committed in plaintext, treat it as compromised and rotate it. A later commit that re-encrypts or removes it does not erase it from git history.