Honor explicitly marking a parameter as not sensitive.

[kaorihinata]

SUMMARY

The way that the no_log parameter is currently implemented in AnsibleModule._log_invocation is overly simplistic, and appears to violate the principle of least astonishment due to its overly brief documentation failing to mention the corner cases for which it appears to have been written. As no_log is currently implemented, it will:

• Not log a parameter value if no_log is truthy.
• Not log a parameter value and complain if the parameter name matches PASSWORD_MATCH and is neither a bool or enum.
• Otherwise, log the parameter.

On the surface (as a module writer), the documentation (see: Protecting sensitive data with no_log) states that by passing no_log=True you are explicitly marking a parameter as sensitive. This makes sense. It would then follow that by passing no_log=False you are explicitly marking a parameter as not sensitive. This is where the current implementation fails. There is currently no way (that I can see) for a module author that has properly developed and tested a module to avoid a warning regarding the no_log parameter if the parameter matches PASSWORD_MATCH (at least, not that I can see in the documentation or HEAD.)

I certainly understand the need to protect users from the whims of careless third party module authors (some of which may have a tenuous grasp on Python at best), but for those of us that write and maintain our own modules professionally it seems like a rather strange choice to provide no avenue for a knowledgeable module author to say, "no, pass_interval really is not a password, and no, there is no other name that would work without causing excessive end-user confusion".

The feature request is basically: can AnsibleModule._log_invocation be adjusted to actually honor no_log=False as the opposite of no_log=True, which it currently does not. I do not believe it would be difficult to implement while maintaining the current behavior where a module author that does not specify either way would be caught by PASSWORD_MATCH.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

lib/ansible/module_utils/basic.py

ADDITIONAL INFORMATION

This change would not be user facing (typically) unless you're a module author. It is needed because, at the current time, there is no way to mark a parameter as explicitly not sensitive (as no_log=False is not being honored effectively) and avoid erroneous messages in the logs. Some authors have been getting around this by choosing more obscure names that diverge from current documentation for their parameters, but you're basically hiding from the problem at that point, and confusing end-users.

Duplicate of a proposed solution to #49465

[ansibot]

Files identified in the description:

• lib/ansible/module_utils/basic.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help