What Vault does not protect · Ansible

Ansible Vault does one thing, and it does it well:

It encrypts data at rest in your repository.

That is the whole scope. Everything people believe it also does, it does not do, and the belief is what turns a good tool into a false sense of completion.

This lesson is the boundary, stated plainly and measured where it can be measured.

A vault-encrypted variable is an ordinary string

The clearest demonstration is the simplest one. The vars file below has db_password as an inline !vault value — encrypted at rest, unreadable in a pull request. Here is what happens once the play runs:

Read-only / Safeencrypted in the file; plaintext in the run— Executed on ansible-core 2.21.3. db_password is a !vault value in the vars file supplied to this play.

$ ansible-playbook -i localhost, vaultleak.yml --vault-id prod@.prod-pass

TASK [The value is vault-encrypted in the repository] *************
ok: [localhost] => {
  "db_password": "REPLACE_ME"
}

TASK [And it templates into anything] *****************************
ok: [localhost] => {
  "msg": "postgresql://billing_ro:REPLACE_ME@db1.example.com/app"
}

The encryption did not follow the value into the run, and it was never supposed to. Once decrypted, the variable is a string like any other. It prints, it templates, it concatenates, it goes into a file, it goes over the wire, it appears in a return value.

That is not a flaw. A secret you cannot use is not a secret you have. The entire point of decrypting it is to use it. But it means every control that applies to strings — no_log, output discipline, log permissions, who can read a ticket — is a separate control that Vault does not provide.

The journey, annotated

Take the diagram from the first lesson of this part and mark it honestly:

Hop	Protected by Vault?	What protects it instead
At rest in the repository	yes	this is the whole job
In a Git object from an earlier plaintext commit	no	rotation; history rewriting
Decrypted in controller memory	no	controller access control
In a `debug` or a registered result	no	`no_log`, and not printing results whole
In `--diff` output	no	`no_log` on the task, or not diffing that task
In `log_path` or a callback log	no	file permissions, directory permissions, umask
As a module argument on the managed node	no	pipelining removes the file; nothing removes the argument
In a temporary file on the target	no	pipelining
In the target process table while the task runs	no	using a module rather than `shell`
In the config file the task wrote	no	file mode, ownership, the target’s own controls
In the target service’s own logs	no	that service’s configuration
In a `backup: true` copy on the target	no	not using `backup` for credential files
In CI job output or artifacts	no	CI configuration and retention policy
Against someone who has the vault password	no	vault ID scoping; where the password lives

One row is yes. That is the accurate picture, and it is worth putting in front of anyone who says “it is fine, it is in Vault”.

Vault does not protect against someone who has the vault password

This sounds too obvious to say. It is not, because of how vault passwords are actually distributed.

If the vault password is in a shared password manager entry that forty engineers can open, then forty engineers can decrypt every production credential in your repository — whenever they like, from wherever they like, with no record that they did.

That is not a weakness in Vault. It is Vault working exactly as designed, applied to a key distribution nobody thought of as key distribution.

Two questions to keep asking, because they have concrete answers:

How many people can decrypt production? If the answer is larger than the number of people who need to change production, the vault ID scheme from earlier in this part is the fix.
Would you know if one of them did? With a password file, no. With a client script fetching from a secret store, yes — every request is logged. That is the strongest single argument for the client-script pattern.

What variable-level encryption specifically does not cover

encrypt_string encrypts values. Not keys, not structure, not tasks, not anything else in the file.

Read-only / Safewhat a reader of this file learns without the password

# Everything here except the value is public information.
db_host: db1.example.com          # your database hostname
db_user: billing_ro               # the account name
db_port: 5432                     # the port
api_endpoint: https://api-internal.example.com/v2
db_password: !vault |
        $ANSIBLE_VAULT;1.2;AES256;prod
        33656432323139626338306532383365366262333432313935643735336539393735303161336162

A reader without the password learns your internal hostnames, your account names, your ports, your API endpoints, the fact that there is a prod vault label, and that a password exists for that account. That is reconnaissance, delivered neatly.

Whether that matters depends on where the repository is. For an internal repository it is usually fine and the reviewability is worth more. For anything public, or anything a wide contractor population can read, the structure itself is worth protecting and file-level encryption is the better choice.

The related limits, which follow from the same fact:

rekey does not touch inline values. It operates on a vault file payload. A file of encrypt_string values is ordinary YAML with encrypted scalars in it, so a password rotation must re-encrypt each value individually — covered with its consequences in the encrypt_string lesson.

Tasks are not encryptable. You can encrypt a variable a task uses. You cannot encrypt the task, the play, or the fact that this playbook configures a payments database. If the existence of something is sensitive, Vault is the wrong layer entirely.

Under the hood

Vault encryption is symmetric: one password, derived into a key, used to both encrypt and decrypt. Three consequences follow, and each explains something people find surprising.

There is no separation between writing and reading. Anyone who can add a secret can read every existing one. There is no equivalent of a public key that lets a junior engineer contribute a credential without being able to decrypt the rest of the file. Asymmetric schemes elsewhere in the industry — age recipients, sops with KMS, git-crypt with GPG keys — do offer this, and it is a genuine reason to look beyond Vault when your contributor set is larger than your should-be-able-to-read set.

Revocation is rotation. There is no per-person key to withdraw. Taking access away from one person means changing the password and re-encrypting, which means telling everyone else the new one. This is why offboarding is so often skipped, and why it should be a scheduled task rather than an event-driven one.

Access leaves no trace. Decryption happens locally with a password the person already holds. Nothing is contacted, so nothing is logged. If you need to know who read a secret and when, the answer is not inside Vault; it is in whatever system hands out the password, which is the argument the previous lesson made for client scripts.

What to use for each hop, in one place

Vault is the answer for exactly one row. For the others:

The run’s own output — no_log on the task that handles the secret, scoped to that task. The next lesson covers what that does and does not buy you.
Log files — a directory only the automation account can enter. Ansible creates the log at the process umask and restricts nothing.
The managed node’s filesystem — pipelining, which removes the module wrapper file entirely.
The target process table — a purpose-built module rather than shell, since a module can declare its parameter sensitive and a command line cannot.
The repository’s history — rotation, not history rewriting, and in that order.
How many people can decrypt — vault IDs with vault_id_match, and keeping production password sources off workstations.
Whether the secret needs to be in the repository at all — an external secret manager, which is the last lesson of this part.

The habit worth building: when you find a possible exposure, name the hop first. The control follows from the hop, and reaching for Vault a second time almost never helps, because if the material is in the repository it is already encrypted there.

What happens if a decrypted secret ends up in a fact, and facts are cached?

This one catches people, because fact caching is a performance feature and nobody associates it with secrets.

Fact caching writes gathered facts to a backend — a JSON file tree, Redis, memcached — so subsequent runs can skip gathering. If a play does set_fact with a decrypted credential, or registers a result containing one and stores it as a fact, that value can be written to the cache.

Which means a secret that was encrypted at rest in your repository is now plaintext at rest in a cache directory, or in a Redis instance that probably has no authentication because it was only ever meant to hold hostnames and package lists.

Three properties make it worse than it first sounds:

It persists between runs. That is the entire purpose of the cache.
Its permissions are nobody’s job. A JSON fact cache is created by whatever process ran first, at whatever umask was in force.
It is invisible in review. No playbook mentions the cache. The secret’s presence there is a side effect of two features interacting.

Two defences, and prefer the first:

Do not put secrets in facts. A decrypted variable is already available to every task in the play; promoting it to a fact adds persistence you did not need. If you find yourself doing set_fact with a credential, ask what that buys over using the variable directly.

Set no_log on the task that would create the fact, and check what your cache backend actually contains:

grep -rl 'REPLACE_ME' /var/cache/ansible/facts/ 2>/dev/null

Run that with a value you know is in play. Finding nothing proves nothing in general, but finding something is decisive — and this is the sort of check that belongs in the pre-commit review checklist this part builds towards.

A vault-encrypted variable is an ordinary string

The journey, annotated

What variable-level encryption specifically does not cover

Knowledge check