no_log, and what it costs you · Ansible

Vault covers the repository. no_log covers the run’s output. Between them they close two of the fourteen hops in this part’s leak table, which is why they belong together and why neither one finishes the job.

no_log is a boolean keyword settable on a task, a block or a play:

Read-only / Safethe three scopes

- name: One task
ansible.builtin.uri:
  url: https://api.example.com/v2/deploy
  headers:
    Authorization: "Bearer {{ vault_api_token }}"
no_log: true

- name: A block of related tasks
block:
  - name: Write the credential file
    ansible.builtin.template:
      src: credentials.j2
      dest: /etc/app/credentials
      mode: '0600'
no_log: true

# And at play level - which this lesson argues against.

There is also a configuration setting that turns it on globally:

Read-only / Safethe global switch, off by default— Executed on ansible-core 2.21.3 with no configuration file present.

$ ansible-config dump | grep DEFAULT_NO_LOG

DEFAULT_NO_LOG(default) = False

Its documented description is “Toggle Ansible’s display and logging of task details, mainly used to avoid security disclosures.” Setting it globally makes every run undiagnosable, which is why the rest of this lesson is about scoping.

What it does suppress

Read-only / Safethe result is replaced, not redacted— Executed on ansible-core 2.21.3. The task is an assert whose condition is false, with no_log set.

$ ansible-playbook -i localhost, leak2.yml

fatal: [localhost]: FAILED! => {"censored": "the output has been hidden
due to the fact that 'no_log: true' was specified for this result",
"changed": false}

The entire result dictionary is replaced by that one key. Not the secret field — the whole thing.

And it holds under verbosity. Verified on 2.21.3 with a module carrying the credential in its arguments:

Read-only / Safecounting occurrences of the secret across verbosity levels— Executed on 2.21.3. The task passes REPLACE_ME as a module argument with no_log set. Each number is a grep count over the full output.

$ for v in '' '-vvv'; do ansible-playbook -i localhost, nolog4.yml $v | grep -c REPLACE_ME; done

0
0

So no_log covers task arguments and task results, in normal output and in -v through -vvv. That is a real and useful control.

The route it does not cover, measured

Now the part that is not in most treatments of this keyword.

Read-only / Safethree no_log tasks, all failing— Executed on ansible-core 2.21.3. Every task has no_log: true. The credential is the literal string REPLACE_ME.

$ ansible-playbook -i localhost, leak2.yml | grep -E 'TASK|ERROR|fatal'

TASK [fail module with the secret in the message] ******************
[ERROR]: Task failed: Action failed: could not connect using REPLACE_ME
fatal: [localhost]: FAILED! => {"censored": "the output has been hidden ..."}

TASK [assert whose fail_msg names the secret] *********************
[ERROR]: Task failed: Action failed: bad credential REPLACE_ME
fatal: [localhost]: FAILED! => {"censored": "the output has been hidden ..."}

TASK [assert whose fail_msg does NOT name the secret] *************
[ERROR]: Task failed: Action failed: credential check failed
fatal: [localhost]: FAILED! => {"censored": "the output has been hidden ..."}

no_log censors the result. It does not censor the failure message.

Look at the first two tasks. no_log: true is set. The result dictionary is censored exactly as documented. And the credential is printed in full, on the line above, in the [ERROR] banner.

The mechanism is consistent once you see it: no_log suppresses the task result. A failure message that the task itself constructed — the msg of ansible.builtin.fail, the fail_msg of ansible.builtin.assert, the error text a module raises — is not the result. It is the exception, and it is reported separately.

The third task is the fix, and it is not a setting. It is writing the message so that it does not name the value:

# Leaks, despite no_log
fail_msg: "bad credential {{ db_password }}"

# Does not leak
fail_msg: "credential check failed for {{ db_user }} on {{ db_host }}"

Identify the account and the target, never the secret. Those are the fields you need in order to diagnose, and none of them is the credential.

This route also reaches the run log. The log capture in the first lesson of this part found the credential three times in run.log, and one of those three came from exactly this [ERROR] line — in a task that had no_log set.

The documented `ANSIBLE_DEBUG` exception, reproduced

The upstream documentation states that no_log does not prevent data being shown when debugging Ansible itself through ANSIBLE_DEBUG. Verified on 2.21.3, and the detail of when it applies is worth having:

Read-only / Safea real module carrying the secret in its arguments— Executed on 2.21.3. The task is ansible.builtin.stat with no_log set and the credential interpolated into its path argument. Each number is a grep count.

$ ansible-playbook -i localhost, nolog4.yml | grep -c REPLACE_ME
ansible-playbook -i localhost, nolog4.yml -vvv | grep -c REPLACE_ME
ANSIBLE_DEBUG=1 ansible-playbook -i localhost, nolog4.yml | grep -c REPLACE_ME

0
0
1

Read-only / Safeand here is the line— Executed on 2.21.3, truncated for the page. The module arguments are logged verbatim as the module executes.

$ ANSIBLE_DEBUG=1 ansible-playbook -i localhost, nolog4.yml | grep REPLACE_ME

4182625 1786484060.79640: done with _execute_module (ansible.builtin.stat,
{'path': '/nonexistent/REPLACE_ME', '_ansible_check_mode': False,
 '_ansible_no_log': True, '_ansible_debug': True, ...

Note '_ansible_no_log': True sitting in the very structure that is being printed. The flag is being carried to the module correctly and the developer-level debug output ignores it, which is what “debugging Ansible itself” means.

A nuance worth knowing: it needs a real module

The same test against a debug task with no_log produced zero occurrences even under ANSIBLE_DEBUG=1.

debug, set_fact and assert are action plugins that run on the controller and never go through the module execution path, so there is no _execute_module call to log. The exception applies to tasks that actually invoke a module on a target.

The practical consequence is a small one but it saves an argument: if you test this yourself with a debug task and see nothing, you have not disproved the documentation. You have tested the wrong kind of task.

The operational rule stands regardless: ANSIBLE_DEBUG=1 output is not safe to share. Not in a ticket, not in a chat channel, not as a CI artifact. It is a developer diagnostic for debugging Ansible, and it is explicitly documented as not honouring no_log.

What it cannot cover at all

no_log controls what Ansible prints. Three things are outside that entirely:

A task that prints the secret itself. A shell task that echoes a credential, or a script that logs its own arguments, produces output that Ansible faithfully suppresses in its result — while the program has already written it to the target’s stdout, its own log file, or wherever else it chose.

A file the task writes. If the point of the task is to place a credential in /etc/app/credentials, the credential is in /etc/app/credentials afterwards. no_log has no opinion about file modes. Set mode: '0600' and an owner, and take the file-permissions material from the Linux course seriously — this is the hop where most credentials on a managed node actually sit.

The managed node’s own logging. sudo logs commands. auditd logs what it is configured to log. The service you just configured may log its connection string on startup. Ansible cannot reach any of that.

The cost, and how to keep it small

Read-only / Safewhat a failed no_log task tells you— Executed on 2.21.3. This is the complete diagnostic information available from the result.

$ ansible-playbook -i localhost, leak2.yml | grep censored

fatal: [localhost]: FAILED! => {"censored": "the output has been hidden
due to the fact that 'no_log: true' was specified for this result",
"changed": false}

A task name and the word censored. No return code, no stderr, no module message, nothing about which host condition caused it.

Which is the argument against play-level no_log, and it is not a theoretical one. A play with no_log: true at play level, failing in production, gives the on-call operator a task name and nothing else. They cannot tell a network failure from a permission failure from a genuinely wrong credential, at three in the morning, on a system they may not have seen before.

Scope it to the task that handles the secret

- name: Fetch the deployment token          # visible, diagnosable
  ansible.builtin.uri:
    url: https://vault.example.com/v1/token
  register: token_response
  no_log: true                              # this one handles the secret

- name: Verify the token was obtained        # visible, diagnosable
  ansible.builtin.assert:
    that:
      - token_response.status == 200
    fail_msg: "token endpoint returned {{ token_response.status }}"

- name: Deploy                               # visible, diagnosable
  ansible.builtin.uri:
    url: https://api.example.com/v2/deploy
    headers:
      Authorization: "Bearer {{ token_response.json.token }}"
  no_log: true                               # and this one

Two tasks are censored; the rest of the play reports normally. The assertion in the middle is the pattern worth stealing: a visible task that checks a censored task’s outcome using a non-secret field. The status code is not the token. It tells the operator whether the fetch worked, which is the question they actually have.

For the tasks that must stay censored, --diff and --check still work, and the recap still tells you which host failed. Combine that with a message that names the account and the host but not the credential, and a censored task is still diagnosable — which is the whole objective.

Under the hood

There is a second mechanism that does the same job better, and it is worth knowing which one is acting.

A module author declares a parameter sensitive in the argument specification:

argument_spec=dict(
    password=dict(type='str', required=True, no_log=True),
)

Ansible then censors that parameter wherever it appears, while leaving the rest of the result intact. So a well-written module carrying a credential does not need a task-level no_log for the credential itself — you keep the return values, the changed status, the error message, and the password is replaced with VALUE_SPECIFIED_IN_NO_LOG_PARAMETER.

That is strictly better than task-level no_log, because it is surgical. Task-level no_log is a blunt instrument you reach for when the module does not know which of its inputs is secret.

Which produces a concrete preference order:

A module that declares the parameter sensitive. Free, precise, and you keep your diagnostics.
Task-level no_log where the module cannot know — uri with a token in a header, command with a credential in an argument.
Block-level where several adjacent tasks all handle the secret.
Play-level essentially never.

And it is one more reason to prefer a purpose-built module over shell. shell receives a string; it has no way to know that one word in it is a credential, so nothing is censored automatically and every protection must be arranged by you.

What happens if a play with play-level no_log fails in production?

This is the break/fix that this part exists to make real, and the sequence matters because the temptation is to do the wrong thing first.

The operator has a task name and censored. The instinct is to remove no_log and re-run — which would print the credential into the incident channel where several people are watching. Do not.

Fix the incident:

Read what is still available. The recap tells you which hosts failed. The task name tells you what it was doing. Whether other hosts succeeded is often the most informative fact available: one host failing is a host problem, all hosts failing is a credential or endpoint problem.
Reproduce out of band. Take the credential from Vault yourself and test the operation manually against one host, in your own session. This gives you the real error message without putting it anywhere shared.
Narrow with a temporary override, not a permanent edit. If you must see task output, re-run against one host with --limit, and remove no_log from the specific task only — never the play — and only in a working copy. That output still must not be pasted.

Then fix the scoping, in the same change as the incident write-up:

Move no_log off the play and onto the tasks that actually handle the secret.
Add a visible assertion after each censored task, checking a non-secret field so the next failure reports something.
Rewrite failure messages to name the account and the host, never the credential — which, as this lesson measured, is the difference between a message that is safe and one that prints the secret past no_log entirely.

The write-up sentence worth remembering: the incident was slow to diagnose not because the secret was protected, but because the protection was applied at the wrong scope.

Knowledge check

Why this matters

no_log: true is one of the most-recommended lines in Ansible and one of the least-examined. It is treated as a switch that makes a task safe, and it is a switch that suppresses one specific thing.

The measurement in this lesson is the part to carry away, because it inverts the usual advice. A task with no_log set can print its credential in full, on a line above the censored result, if the message it constructs names the value — and that same line lands in the run log. The keyword did its documented job perfectly and the secret escaped anyway.

Which leads to the discipline that actually works: never write a secret into a message, a name, a when, or anything else you would want to read during an incident. Then no_log handles the arguments and the results, your messages stay useful, and the two controls cover different ground instead of one of them being trusted to cover both.