Visibility to possible sensitive data that we may not require.

[cwebster61083]

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]

@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]

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]

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

[Serviceguru]

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]

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