When you use a loop in an ansible task, e.g. with_items or with_dict, a dump of the item is included in the output. Sometimes these items contain secure infomation which it is undesirable to have output on screen, for example:
`
I was facing some similar problem.
Mine is just that the dictionary being included in the output has too many values that it makes output messy and I would prefer just to include dict.key at the item=() output.
It would be really nice to be able to decide if all the item or just a part of it is printed to the output.
This is something I’d be quite interested in as well. All of our private data is stored via ansible-vault, but then it winds up being displayed in plain text as the playbook executes. In a slightly contrived example, I’ve got an encrypted users.yml file that has user passwords. In my playbook, I pass the variable to the users module as “with_items: users”, and wind up seeing all of the passwords, exactly like Thom pasted above.
Certainly the argument can be made that since I knew the vault password, I could go look up that information anyway, but I’m more concerned with someone looking over my shoulder, or the output being some where I don’t control (Jenkins, for instance).
So nothing valuable to add to this discussion, only hoping to see what others have done to work around this!
This is indeed a security weakness (unnecessary exposure of sensitive data). So, I propose the introduction of a new playbook directive called ‘sensitive_keys’ with a list of keys that are considered to hold sensitive data. Then, at output (logs / console output), all variables would be recursively checked if they contain a key that is included in the ‘sensitive_keys’ list. If a key is matched, its value would be replaced with a ‘hidden’ version. For example: So, the following var: would have this ‘hidden’ version at logs / console output: As a proactive measure, if ‘sensitive_keys’ is not explicitly set, it could include ‘password’ by default. Also, for debugging purposes or to speed up things if users are not interested in that measure, a configuration option that disables all this could be introduced. What do you think?
We’re not going to be adding anything called “sensitive_keys”, especially as filtering is not just about sensitivity.
Tasks take a “no_log: True” attribute to prevent their output from hitting syslog, easiest is to also make this automatically dock the verbosity in the callback.
Ok, this would surely be a fine solution to the problem of being able to protect from over the shoulder watchers. I was about to open a new github issue but it seems there are at least 3 open issues for this. 