ansible-vault — Secrets You Can Put in the Repository

Summary in one line

Vault is not a tool that takes secrets out of the repository; it keeps them inside the repository as ciphertext and decrypts them only at run time.

Why this is needed

Adding .env to .gitignore does not make it safe. Environment variables can be read as they are on the same host through /proc/PID/environ, and they get carried out in crash reports, CI logs, and container image layers. And a more important question remains — when a secret leaks, can you revoke and replace that key within minutes? In most teams the answer is "we don't know," because nobody knows how many copies exist and where.

Vault solves half of this problem. Because the secrets are in the same repository as the code, you can count how many there are and where, they go through review, and a history is kept. The other half (automatic rotation, short-lived credentials) is the domain of an external secrets manager.

How it works

Vault is AES256 symmetric encryption. The key is a single password, and you hand over that password through a file or a prompt.

Command	What it does
ansible-vault create	Creates a new encrypted file
ansible-vault encrypt	Encrypts an existing plaintext file
ansible-vault view	Only decrypts and shows the content
ansible-vault edit	Decrypt → edit → re-encrypt
ansible-vault rekey	Re-encrypts with a new password
ansible-vault encrypt_string	Encrypts just one value and inlines it in YAML

The first line of an encrypted file is a header of the form $ANSIBLE_VAULT;1.1;AES256. If this line is missing, the file is plaintext. It is the first thing you look at when auditing.

encrypt_string encrypts just one value, not the whole file. The rest of the variables file stays plaintext, so you can read the diff, and only the secret remains as ciphertext. In practice this is used more often.

--vault-id distinguishes several keys by label. If you write it like prod@파일, the label is embedded in the header, which prevents accidents caused by mixing up production and development keys.

Always attach no_log: true to tasks that handle secrets. Otherwise the value you worked so hard to encrypt is printed in plaintext in the execution log. Log collection systems usually have broader access permissions than applications.

What it looks like in the field

First, the location of the password file. Keeping .vault_pass inside the repository is like taping the key next to the lock. Always add it to .gitignore and set its permission to 600.

Second, revocation comes first. If you find a secret committed in plaintext, the order is revoke → investigate impact → clean up history. Starting with rewriting history is the wrong order — a published value may already have been collected by automated scanners, and it remains in forks, clones, and CI caches. Cleaning up history is not a measure that undoes the leak; it is hygiene work that reduces recurrence.

Third, rekey invalidates the old key. After a rekey, you cannot open that file with the old password. If the key is used by several people, you have to coordinate when to switch.

Other channels through which secrets leak

Even if you encrypt the files and attach no_log, a few more channels remain through which values flow out. It is good to write them down as a checklist.

Command-line arguments. If you pass a value as an argument to a command, other users on the same host can see it as is in the process list. If there is a way to pass it through a file or standard input, use that.

Shell history. If a value is included in a command typed by hand, it stays in a file as is. That file is usually included in backups too.

Error messages and exceptions. It is common for code to log a failed request in its entirety, and the authentication header is inside it. When you log requests, you must decide in advance what to strip out, and that list must be updated every time a new header appears.

Intermediate files. While a configuration file is being created from a template, a temporary file is sometimes placed with default permissions for a moment and then deleted. Even for a short moment, another process can read it at that point, so it must be created with narrow permissions from the start.

Backups and snapshots. An encrypted file is fine to back up as it is, but if a decrypted output remains on the server, it gets included in the backup. That is why deciding the permissions and location of deployment outputs is part of secrets management.

One step further is detection. There are tools that catch a secret entering the repository in plaintext at the commit stage or in CI, and if you put one in place you do not have to go through the "revoke → investigate → clean up" described earlier at all. A rule that relies on people's attention will fail someday, but a check that blocks the commit works every time.

What you will do in the next lab

You create a password file safely, encrypt a whole variables file, and encrypt just one value inline. In a playbook you use the decrypted value to create a file with permission 600, and use no_log to block log leaks. After rekey and vault-id, you finally audit the whole repository.