Passwords in Puppet Log files

asked 2014-10-07 03:13:11 -0600

asktbt
170 ●10 ●14 ●21

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?

Thanks for all opinions.

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2014-10-10 16:10:56 -0600

gabe_sky
210 ●4 ●7

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:

https://docs.puppetlabs.com/reference...

edit flag offensive delete link

Comments

I overlooked that option. Thanks for pointing it out.

cbarbour ( 2014-10-10 19:01:14 -0600 )edit

add a comment

answered 2014-10-08 01:58:07 -0600

cbarbour
977 ●1 ●7 ●16 http://www.taos.com/

Here are some techniques to help obfuscate your passwords:

Reduce or disable logging output on the client
Disable the show_diff option (Helps avoid passwords in your reports.)
Disable the catalog_cache_terminus; set catalog_cache_terminus="". (All your passwords are available in the catalog; this prevents the catalog from being written to disk.)
Avoid placing passwords in resource names; use the command parameter and a friendly resource title. (Resource names appear in verbose log messages and reports. Parameters appear in fewer places.)
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.

edit flag offensive delete link

add a comment