Ansible no_log: Protect Sensitive Data in Playbook Output
By Luca Berton · Published 2024-01-01 · Category: troubleshooting
How to use Ansible no_log to hide sensitive data from output. Protect passwords, API keys, and tokens in playbook logs with practical examples.
As an automation expert, you are likely familiar with the benefits of using Ansible as a configuration management tool. Ansible is a powerful automation platform that allows you to manage your infrastructure and automate repetitive tasks. However, one critical concern when using Ansible is the protection of sensitive information such as passwords, access keys, and other confidential data. Fortunately, Ansible provides a way to protect this information using the no_log statement.
The no_log statement is a powerful feature in Ansible that allows you to prevent sensitive data from being logged or stored in your logs. This statement is particularly useful when working with playbooks that involve sensitive data such as passwords or access keys. By default, Ansible logs all output to the console and to a log file. However, when the no_log statement is added to a task, Ansible will not log any output from that task to the console or log file.
To use the no_log statement, you simply need to add it to the task where sensitive information is used. For example, if you are using a task that involves logging into a server using a password, you can add the no_log statement to the task to prevent the password from being logged. Here's an example:
In this example, the no_log statement has been added to the task that involves logging into the server. This ensures that the password is not logged or stored in any logs. It's essential to note that the no_log statement only applies to the task where it is used. If the same sensitive data is used in another task, the no_log statement must be added to that task as well.
In addition to the no_log statement, Ansible also provides other methods to protect sensitive data, such as using Ansible Vault. Ansible Vault is a feature that allows you to encrypt sensitive data using a password. The encrypted data can then be stored in your playbooks or inventory files, and Ansible will automatically decrypt the data when it's needed.
Links • Protecting sensitive data with no_log
Conclusion
In conclusion, protecting sensitive information is critical when working with Ansible. Using the no_log statement is one way to prevent sensitive data from being logged or stored in logs. By adding the no_log statement to tasks where sensitive data is used, you can ensure that your logs don't contain any confidential information. Additionally, Ansible Vault is another powerful tool that you can use to encrypt sensitive data. By combining these methods, you can be confident that your sensitive information is protected when using Ansible.
Basic no_log
Output shows censored instead of task details.
When to Use no_log
Conditional no_log
no_log in Loops
loop_control label (Alternative)
For loops where you want partial visibility:
Play-Level no_log
What no_log Hides
| Hidden | Not Hidden | |--------|-----------| | Task arguments/results | Task name | | Variable values | Changed/ok/failed status | | Command output | Task timing | | Loop item details | Host name |
Debugging with no_log
FAQ
Does no_log prevent Ansible from logging to syslog?
Yes — no_log: true prevents data from appearing in stdout, callbacks, syslog, and AWX/AAP job output.
Can AWX/AAP override no_log?
No — no_log is respected by AWX. Admins cannot see censored data in job output.
Should I use no_log on every task with variables?
No — only on tasks that handle actual secrets (passwords, keys, tokens). Overusing no_log makes debugging extremely difficult.
What about ansible-vault?
Vault encrypts data at rest (in files). no_log hides data at runtime (in output). Use both together for comprehensive protection.
Basic no_log
Without no_log, the hashed password appears in task output.
What no_log Hides
Common Use Cases
Conditional no_log
no_log with Loops
Debugging with no_log
Global no_log (ansible.cfg)
Vault + no_log (Best Practice)
What no_log Does NOT Hide • Task name • Host name • Changed/ok/failed status • Task start/end time
It hides: • Module arguments • Return values • Registered variable content
Callback Plugin Considerations
FAQ
no_log hides errors — how do I debug?
Temporarily set no_log: false, or run with -vvv. The verbose output shows where censored data would appear.
Does no_log protect data at rest?
No — no_log only affects console/callback output. Use ansible-vault to encrypt data at rest in files.
Should I use no_log on every task?
Only on tasks that handle secrets (passwords, tokens, keys). Overusing no_log makes debugging difficult.
Basic no_log
What no_log Hides
Common Use Cases
Conditional no_log
Debug Without Exposing
no_log on Loops
Environment Variables
Global no_log (ansible.cfg)
FAQ
Does no_log affect Ansible Tower/AAP logs?
Yes — no_log: true censors output in Tower/AAP job logs too.
Can I use no_log on a block?
What if I need to debug a no_log task?
Temporarily set no_log: false or use -vvvv (note: verbose mode may still show some censored data in newer Ansible versions).
Related Articles • Ansible Vault Guide • Ansible Inventory Guide
Category: troubleshooting