Restrict access to the Puppet master by default #215
Conversation
| @@ -12,6 +12,10 @@ | |||
| $open_ssl_listen_port = undef | |||
| $postgres_listen_addresses = 'localhost' | |||
|
|
|||
| $certificate_whitelist_file = '/etc/puppetdb/certificate-whitelist' | |||
There was a problem hiding this comment.
This path is no longer what we use for the latest version of the module - that is, be careful to lift the path from other variables, not static like this - this isn't a good location to store it for PuppetDB 3.x for example.
|
@michaelweiser so making this default now, means it will be a breaking change for some. Can you see a world where this option is for now optional and the default behaviour is to not provide a certificate-whitelist? This will allow us to get the feature right, allow users of current module to test it out without breaking etc. |
|
@kbarber: I would advocate for making the default enabled since otherwise any root or puppet user on any Puppet client remains able to download the complete catalogs of all other clients from PuppetDB including any and all passwords and other sensitive information contained therein. I can not see how anyone would have a legitimate use case for this behaviour. I would like to see it improved and users made aware of it by the fact that they actively have to open PuppetDB up to connections from more hosts. But if your judgement is that this does not outweigh the hassle of breakage, we can certainly leave it disabled for now. I just realised, though: There might be a need to more intelligently determine a list of possibly multiple Puppet masters needing access to this one PuppetDB than just looking at BTW: New commit regarding the changed |
Its more that we have a behaviour now, breaking it would mean shipping a 6.0 by our versioning rules. I think we could switch this on by default by 6.0, but this can't go out as a 5.1.0 change. My suggestion is to slot the feature in without it enabled today, and we switch the default later in a 6.0. This also means the feature can be 'bedded-in' also.
I think if you need multiple puppet masters, possibly better to provide a static list. Users could query this information from elsewhere, but its fragile since this can create bad chicken/egg breakages if done incorrectly. |
Add the option to set up a certificate whitelist file and configure it in PuppetDB so that only specific hosts (i.e. the Puppet master(s)) have access.
|
Here's a new patch with changed default and spec tests even. Yay! :) |
Restrict access to the Puppet master by default
Set up a certificate whitelist file and configure it in PuppetDB so that
only the Puppet master has access by default.