This is GLOBAL PROBLEM for every organization who uses ansible. If we solve this, the security risk will be reduced a lot in terms of exposing credentials or secrets. When using Ansible to manage infrastructure and application deployments, secret variables (such as passwords, API keys, and other sensitive data) are sometimes displayed in the task output. We can achieve this by using no_log: true however, entire task output is hidden when we use no_log: true. Output is required for auditing, logging and troubleshooting so the current solution does not met the needs.

We need output with secrets masked. In Ansible Automation platform, if we use surveys with password as category then those are getting redacted. However if we pass as extra vars or any variables either from credentials or from a playbook, the secrets are not redacted like in survey type.

We would like Red Hat to implement a feature in Ansible that allows for automated redaction of secret variables in the output logs, ensuring that sensitive information is never exposed.

The feature should work as follows:

1. Identify and redact secret variables or specific patterns in the output.
2. Be configurable to allow users to define which variables or data patterns should be treated as sensitive.
3. Be compatible with no_log: true and extend its capabilities by ensuring that sensitive data in nested structures or unexpected outputs is also redacted.
4. Provide options for partial redaction (e.g., displaying ******** or the first/last few characters).

Expected Benefits:

• Enhanced Security: Ensures sensitive data is not inadvertently exposed.

• Improved Compliance: Helps meet compliance requirements for data protection and auditing.

• Ease of Use: Simplifies secret management, especially in environments with complex playbooks.

Relevant Use Cases:

• Managing cloud resources where API keys are used in module execution.

• Deploying applications where passwords or tokens are passed to Ansible tasks.

• Debugging large playbooks with detailed output that may inadvertently expose secrets. 

Note that the linked cases particularly AAPRFE-1138 have many support cases linked to it and there is high demand for this feature.