puppetlabs / puppetlabs-puppet_operations_appliance

Puppet Enterprise tool to create a central place for logging, metrics and maintenance
2 stars 9 forks source link

Visibility to possible sensitive data that we may not require. #29

Open cwebster61083 opened 3 years ago

cwebster61083 commented 3 years ago

One example of would be ssl private keys stored in /var/pesupport/master.puppetdebug.vlan/etc/puppet/ssl/private_keys. Another example would be eyaml keys if present.

MartyEwings commented 3 years ago

@dylanratcliffe this had not occurred to me before, I'm not too worried about the SSL stuff, i don't think our customers would mind that too much, but things like EYAML keys could be a bone of contention, thoughts on this based on your field experience?

dylanratcliffe commented 3 years ago

Yeah there's a good chance that people would be storing their private keys in /etc/puppetlabs and it could be an objection. Would be good to see if there is an easy way to exclude access to these...

jarretlavallee commented 3 years ago

There could also be some concerns about sensitive data in some of the non-puppet logs in /var/log.

Serviceguru commented 3 years ago

I'd like to avoid any chance we can see private keys or any other content that is too risky and unnecessary to even access. Same as above re: non-puppet logs. In the event the customer experienced a breach, we must avoid even a chance of being a "suspect" because we have access.
Thanks

MartyEwings commented 3 years ago

The option to Narrow the feild to /<etc/opt/var>/puppetlabs is a possibility.

The idea there may be non puppet logs in /var/ is a potential, but at the same time we recommend nothing runs on infra other than puppet, at most sometimes there are splunk, zabbix and other monitoring tools running

I think we move forward as is, have this as a discussion topic, and potentially tighten the mount points, or make them dynamic, IE allow the customer to specifically input the mount locations, or leave as default as our alpha customers feedback