No. The no_log: true setting keeps a task's values out of Ansible's normal output and logs, but the documentation says it does not affect debugging output, and it does not stop data showing when you debug Ansible itself with ANSIBLE_DEBUG.
What Ansible logs by default
By default Ansible sends output about plays, tasks and module arguments to the screen on the control node. If you capture that output in a log, using log_path for example, any secret in the output is exposed, such as passwords and usernames. The display_args_to_stdout setting adds variable values to the output to tell similar tasks apart, which makes the exposure larger.
What no_log does
Mark tasks that handle secrets with no_log: true. You can set it on a whole play, but the FAQ points out this makes debugging hard, and recommends applying it to single tasks once a playbook is finished.
- name: Create database user
community.postgresql.postgresql_user:
name: app
password: "{{ db_password }}"
no_log: true
Where secrets still leak
| Source | Covered by no_log |
|---|---|
| Normal task output | Yes |
| Debug output | No |
| ANSIBLE_DEBUG output | No |
| A registered variable printed later with the debug module | Not unless the later task is also protected |
| Logs on managed nodes | Review no_target_syslog and syslog settings |
Habits that reduce exposure
- Put
no_log: trueon every task that takes a password, token or key as an argument. - Never run playbooks with secrets in debug mode in production.
- Keep verbose levels low in shared job logs.
- Store secrets in an encrypted vault or a secrets manager, not in plain variable files.
- If you need history, use a controlled platform rather than loose log files, since the documentation points to AWX or Red Hat Ansible Automation Platform for review of output history.
- Rotate any secret that appeared in a log.
Pipelines and shared logs
CI systems keep job logs for a long time and often let many people read them. A secret that reaches a job log may outlive the credential's intended life. Decide who can read pipeline output, how long it is kept, and whether masking features in your CI system are on. Masking is a second layer. It should not replace no_log on the task itself.
A quick test
Run the playbook in a throwaway environment with a fake secret, then search your log files and job output for it. If you can find it, so can anyone with log access.
Quick check
Should I set no_log on the whole play?
The FAQ says it is possible but makes debugging difficult, and suggests single tasks.
Does no_log encrypt anything?
No. It only suppresses output of a task's values.
Is a vault password the same as a no_log value?
No. Vault encrypts stored data. no_log controls what is printed.
Safeguard offers SBOM and dependency scanning and policy gates that can block a pull request on findings, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
