This is related to the new Secret masking feature of ansible-core 2.22. I’ve been looking into adjusting the collections I maintain to this in the last weeks, and there are two categories where I think a lot of questions are still open of how collection plugins should adjust to these changes: lookup plugins and callback plugins. Since callback plugins are somewhat more important (in my opinion), I wanted to first start a discussion on these.
I’ve been working on / reviewing four PRs on callback plugins in community.general (PR 1, PR 2, PR 3, PR 4), and in them and in other discussions I had similar questions kept popping up. The official documentation on secret masking in callback plugins is on docs.ansible.com. Basically plugins which simply dump stuff (either directly or as JSON) to Display don’t have to do anything. I’m mainly interested in other kind of plugins, which send data to some service (speech synth, mail server, chat service, whatever kind of database, …).
Some information, namely the CallbackResult.result resp. CallbackResult._result fields, are already masked by ansible-core before passing the information to the callback. This covers already a lot of output, but there is more:
- The task and play names. I would mask these, since they can use Jinja templates and thus can contain secrets.
- The host names. I would not mask them, even if they could contain secrets, since they are pretty essential to making the callback result usable.
- Other result attributes such as
task,_task,_task_fields,warnings,deprecations,exceptions. These are not masked, but definitely should be when used in callbakc output as they can contain secrets. - The statistics passed to
v2_playbook_on_stats. I would not mask these, even if a “secret” number appears in them. (IMO masking them would leak more info about the secrets than protect something.) - The playbook’s filename, the user’s home directory, similar properties of the system the controller runs on: I would not mask it.
- The system username, or other system-specific info: I would not mask it.
- Possibly templated filename parameters such as
missing_file,imported_file: I would mask these, since especially formissing_fileit is quite possible that thie is because of an template error which inserted something like{"name": "foo", "password": "hunter2"}into a string isntead of itsnamefield, and thus potentially contains secrets.
What do you think? Are there more values that should be potentially masked / definitely not masked?