What is Ansible Vault, and what does encrypting a file with it protect you against — and what does it not protect you against?

## The problem it solves Ansible's whole value proposition is that configuration lives in files you review and version-control. But real playbooks need database passwords, API tokens, TLS keys and licence strings, and those must not be committed in plaintext. Ansible Vault is the built-in answer: encrypt the sensitive files (or the sensitive values inside them) with a password, commit the ciphertext, and give the password to the humans and machines that actually run the playbook. ## What encryption actually does to the file `ansible-vault encrypt secrets.yml` replaces the file's contents in place. What is left is a text header followed by a hex-armoured payload: ``` $ANSIBLE_VAULT;1.1;AES256 34643766316239383066396336626635383234... ``` The header names the format version and the cipher; the payload is the encrypted body plus an authentication tag. The password you type is not used directly as a key — it is run through a key-derivation function with a random salt, which is why encrypting the same file twice produces different ciphertext. Because the whole file is one blob, nothing about its structure survives: not the YAML keys, not the number of variables, not which line changed between two commits. The main subcommands you will be asked to name: - `ansible-vault create secrets.yml` — open `$EDITOR` on a new file and encrypt on save. - `ansible-vault encrypt secrets.yml` / `ansible-vault decrypt secrets.yml` — convert an existing file in place. `decrypt` leaves plaintext on disk, which is what people accidentally commit. - `ansible-vault edit secrets.yml` — decrypt to a temporary file, open the editor, re-encrypt on save. The normal way to change a secret. - `ansible-vault view secrets.yml` — print the plaintext to stdout without persisting it. - `ansible-vault rekey secrets.yml` — re-encrypt the same content under a new password. - `ansible-vault encrypt_string` — encrypt one scalar so it can be pasted into an otherwise plaintext YAML file. ## How the password reaches the run Encrypted content is useless unless `ansible-playbook` can unlock it, and Ansible offers exactly three shapes for that: prompt interactively (`--ask-vault-pass`), read a file (`--vault-password-file secret.txt`), or use a labelled identity (`--vault-id prod@prompt`). The password file may be a plain file containing the password on one line, or an executable script whose stdout is taken as the password — that hook is how teams fetch the password from an external secret manager instead of storing it. The same file can be set once via the `ANSIBLE_VAULT_PASSWORD_FILE` environment variable or the equivalent `ansible.cfg` setting. Encrypted files are decrypted lazily, so a playbook that never loads `secrets.yml` never needs the password at all. ## The security boundary, stated honestly This is the part interviewers listen for. **It is confidentiality at rest, nothing more.** Ansible Vault is a symmetric cipher with a shared password. There is no per-user key, so you cannot revoke one engineer's access without rotating the password and re-encrypting everything. There is no audit trail: the file cannot tell you who decrypted it. There is no versioned secret store, no lease, no automatic expiry. **Git history is forever.** If a secret was committed in plaintext before someone thought to encrypt it, encrypting it today changes nothing — the old commit still holds the value. That secret must be rotated at its source, not merely encrypted. **Decryption puts plaintext in play.** Once a vault variable is loaded it behaves like any other variable. A `debug` task, a registered result, a template rendered with `-vvv`, or a module that echoes its arguments can print it. Mark such tasks `no_log: true`, and remember the same value may be written into a config file on the managed host with whatever permissions your `template` or `copy` task set. **The password itself is the real secret.** A vault password sitting in `~/.vault_pass` on a shared jump box, or checked into the repo "temporarily", collapses the whole scheme. Interviewers ask "where does the vault password live?" precisely because the answer exposes whether the story is real. ## When it is the right tool Ansible Vault fits small-to-medium estates where the secrets change rarely, the team is small enough to share one or a few passwords, and everything already lives in a git repository. When you need per-team access control, short-lived credentials, dynamic database logins, or an audit log, the honest answer in an interview is that a dedicated secret manager is the right layer and Ansible reads from it at run time, with Vault reserved for the bootstrap credential that unlocks that manager.