Passwords in Puppet Log files

we're running Puppet in v3.0.1. When introducing tools to manage log files from central points (like e.g. Logstash, we became more aware of the passwords that are stored in the puppet log files on the nodes.
When puppet sets or re-sets a password in the configuration, based on the module technique those show up in the log files. A file_line with a match (coming with stdlib to only control the credentials in a configuration file will become distributed that way to other locations and accessible through log-analyzing tools as well.
Currently we adjusted filters in the log-tools to suppress the password information being populate back into the analyzing tools.

Nonetheless is there a known way (or updated puppet version) that can reduce or limit the output into the log files on the client side in order to avoid credentials showing up in the node log files?
Are there any other suggestions or workarounds?

2 Answers

Have you considered setting a loglevel metaparameter for just the resources that you're trying to keep out of the logs? If you set it low enough, and your syslog config is discarding that level, you might have a quick fix. Docs are here:

Where possible, use other forms of authentication. The Puppet SSL certificate can be used, if your infrastructure trusts the CA cert, and maintains an access list.

Wrap passwords containing resources in if/then blocks, and only send them to the client when needed (note that class parameters are still sent to the client, so you might not want to parameterize your passwords with this approach.)

Centralize your logs; do not write them to the client.

Consider distributing passwords by other means, such as mcollective.

Write a post-run script that sanitizes your system.

All of these techniques simply obfuscate the passwords; any password sent to the client can be intercepted by a privileged user of that machine. The best way to secure your network is to avoid password reuse, or avoid using passwords at all.

There are some easy ways to generate unique deterministic passwords. One way would be to have the master hash a secret word with the clients certname. That password would be unique to that client, can be automatically generated by the master, but could not be generated for unathorized machines without knowing the original secret word. You could then distribute those passwords to other hosts using exported resources or other methods.