Secret-Handling Mistakes

Encrypting a secret at rest is wasted if a task prints it to the terminal, the CI log, or a registered variable on the next debug. Ansible defaults to showing task arguments and results, so a decrypted vault_db_password can leak through -vvv, a registered variable, a debug of the wrong thing, or a command line that any user on the host can read in the process table.

no_log: true is the switch that stops a task from printing what it is handling. This topic is a catalog of the channels through which a secret leaks after it has been decrypted, and the one line that closes most of them. The encryption in the earlier topics protects the secret at rest; this one protects it during the run.

no_log Suppresses Task Output

no_log: true on a task replaces its arguments and result with censored in all output. It is the one line you add to any task that touches a secret, and once it is there the value never reaches the terminal or the CI log — not in the task banner, not in the result, not even at high verbosity. Add it to the task that sets vault_db_password and the password is invisible no matter how the run is invoked.

- name: Render the app environment file with the DB password
  ansible.builtin.template:
    src: app.env.j2
    dest: /etc/larkspur/app.env
    mode: "0600"
  no_log: true           # args + result become "censored" in all output

Verbosity Leaks

-vvv dumps full module arguments for every task, which is exactly what you want when debugging an unrelated failure and exactly what you do not want on a task that passes vault_db_password as an argument. Without no_log, that password prints in plaintext under verbose debugging — and the engineer running -vvv was chasing a different bug entirely and never thought about the secret.

This is why no_log is the only reliable guard rather than "just do not run verbose." no_log overrides verbosity: the task stays censored at -vvv as surely as at the default level. You cannot count on every future run, by every engineer, to avoid the verbose flag — so you censor the task instead and stop worrying about who runs it how.

Registered Variables and debug

The subtler leak is not the secret task — it is the innocent-looking debug two tasks later. Register a command's result into a variable and that variable holds whatever the command returned, secrets included. Then debug: var=result for ordinary troubleshooting dumps the captured value, and the password lands in the log from a task whose job had nothing to do with the secret.

The fix is discipline about what you register and what you debug. Never debug a registered variable that might hold a secret, and if you must inspect one, scope no_log to the surrounding task and print only the non-secret fields. The leak rides in on the captured result, so treat any registered result that touched a secret as itself sensitive.

command Args in the Process Table

Passing a password as a command or shell argument — psql ... --password=s3cr3t — puts it in the process list, where any user on the managed node can read it with ps while the command runs. It also lands in your shell history and in the playbook's own verbose output. The process table is the worst of these, because the exposure is to anyone with a shell on the host, not just to the run's log.

The fix is to never put a secret on a command line. Prefer a module that takes the password as a parameter — community.postgresql.postgresql_db accepts login_password — so the value goes through Ansible's argument channel rather than the process arguments, or pass it through the environment with environment:. Either way the secret stays out of ps, and you pair it with no_log to keep it out of the log too.

The Unencrypted Vault File

The last leak is at rest, and it is permanent. Commit vault.yml before encrypting it, or ansible-vault decrypt it for a quick edit and forget to re-encrypt before committing, and the cleartext lands in git. Even one such commit means the secret is in history forever — a git show on the old commit reveals it long after the current file is encrypted.

Because the exposure is permanent, the fix is rotation, not re-encryption. Encrypting the current file protects future commits; it does nothing about the plaintext already in history. The exposed vault_app_secret_key must be changed at its source so the value in git history is dead. And the way to avoid the whole situation is to use ansible-vault edit, which never writes cleartext to disk, instead of the decrypt-then-encrypt dance that leaves a plaintext file waiting to be committed by accident.