Hello, Is it possible to control from which nodes is it allowed to execute commands like "replace catalog" and "replace facts", and which nodes can only do queries (but no changes)? It seems like once someone could access the service through http or https (depending on jetty.ini settings) can do both. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/taXhYNOGLZgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Friday, October 26, 2012 7:24:18 AM UTC-7, ak0ska wrote:> Hello, > > Is it possible to control from which nodes is it allowed to execute > commands like "replace catalog" and "replace facts", and which nodes can > only do queries (but no changes)? It seems like once someone could access > the service through http or https (depending on jetty.ini settings) can do > both. > >Unfortunately, this isn''t currently possible, though it''s certainly something we''d like to provide in the future. Currently the only restriction that can be made is a whitelist of certnames which are allowed to talk to the API, for both read and write alike. Until this is supported by PuppetDB itself, you could use a proxy to allow only certain routes. If we were to add this feature, would it be sufficient to just have "no access", "read access", and "read/write access" as categories, or would you need something more granular than that (for instance, can query metrics but not facts)? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/6rioj916zpAJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
We''re still just getting familiar with PuppetDB, so at this point it''s too early to say how fine grained we need this feature to be. We''ve already set up a proxy (as you recommended) and this solution suites us for now. On Friday, October 26, 2012 8:56:26 PM UTC+2, Nick Lewis wrote:> > On Friday, October 26, 2012 7:24:18 AM UTC-7, ak0ska wrote: > >> Hello, >> >> Is it possible to control from which nodes is it allowed to execute >> commands like "replace catalog" and "replace facts", and which nodes can >> only do queries (but no changes)? It seems like once someone could access >> the service through http or https (depending on jetty.ini settings) can do >> both. >> >> > Unfortunately, this isn''t currently possible, though it''s certainly > something we''d like to provide in the future. Currently the only > restriction that can be made is a whitelist of certnames which are allowed > to talk to the API, for both read and write alike. > > Until this is supported by PuppetDB itself, you could use a proxy to allow > only certain routes. > > If we were to add this feature, would it be sufficient to just have "no > access", "read access", and "read/write access" as categories, or would you > need something more granular than that (for instance, can query metrics but > not facts)? >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/qXDt2-87I4kJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi Nick, My biggest concern is that nodes can access other nodes resources stored in PuppetDB, which effectively means that parameters like passwords and other sensitive information is exposed. I also wonder if PuppetDB has any sense of environments? What I mean, does it separate data in environments, so for example, NODE1 being in development environment can access NODE2''s resources which is in production environment? Thanks, Vaidas On Friday, 26 October 2012 19:56:26 UTC+1, Nick Lewis wrote:> > On Friday, October 26, 2012 7:24:18 AM UTC-7, ak0ska wrote: > >> Hello, >> >> Is it possible to control from which nodes is it allowed to execute >> commands like "replace catalog" and "replace facts", and which nodes can >> only do queries (but no changes)? It seems like once someone could access >> the service through http or https (depending on jetty.ini settings) can do >> both. >> >> > Unfortunately, this isn''t currently possible, though it''s certainly > something we''d like to provide in the future. Currently the only > restriction that can be made is a whitelist of certnames which are allowed > to talk to the API, for both read and write alike. > > Until this is supported by PuppetDB itself, you could use a proxy to allow > only certain routes. > > If we were to add this feature, would it be sufficient to just have "no > access", "read access", and "read/write access" as categories, or would you > need something more granular than that (for instance, can query metrics but > not facts)? >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
You can specify a whitelist for which nodes are allowed to contact puppetdb at all (and restrict it to only your puppetmaster), and then just send the rest of the read queries through the proxy. If you only allow the /v2/nodes & /v2/facts endpoints through the proxy clients can''t read for example file contents of file resources. You could also use the filtering proxy I described in the following post to filter the resources endpoint to hide all parameters: https://groups.google.com/forum/?hl=en&fromgroups=#!searchin/puppet-users/puppetdb$20proxy/puppet-users/5IgsoZi6rVY/TJfaqoR7zc0J On 13 February 2013 18:26, Vaidas Jablonskis <jablonskis@gmail.com> wrote:> Hi Nick, > > My biggest concern is that nodes can access other nodes resources stored > in PuppetDB, which effectively means that parameters like passwords and > other sensitive information is exposed. > > I also wonder if PuppetDB has any sense of environments? What I mean, does > it separate data in environments, so for example, NODE1 being in > development environment can access NODE2''s resources which is in production > environment? > > Thanks, > Vaidas > > > On Friday, 26 October 2012 19:56:26 UTC+1, Nick Lewis wrote: >> >> On Friday, October 26, 2012 7:24:18 AM UTC-7, ak0ska wrote: >> >>> Hello, >>> >>> Is it possible to control from which nodes is it allowed to execute >>> commands like "replace catalog" and "replace facts", and which nodes can >>> only do queries (but no changes)? It seems like once someone could access >>> the service through http or https (depending on jetty.ini settings) can do >>> both. >>> >>> >> Unfortunately, this isn''t currently possible, though it''s certainly >> something we''d like to provide in the future. Currently the only >> restriction that can be made is a whitelist of certnames which are allowed >> to talk to the API, for both read and write alike. >> >> Until this is supported by PuppetDB itself, you could use a proxy to >> allow only certain routes. >> >> If we were to add this feature, would it be sufficient to just have "no >> access", "read access", and "read/write access" as categories, or would you >> need something more granular than that (for instance, can query metrics but >> not facts)? >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscribe@googlegroups.com. > > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- Erik Dalén -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
> My biggest concern is that nodes can access other nodes resources stored in > PuppetDB, which effectively means that parameters like passwords and other > sensitive information is exposed.If the data is not exported this shouldn''t be the case ordinarily. Obviously though if your content is uncontrolled it is possible for someone to use a function from the puppet master to query data (FYI - functions run on the puppetmaster, not the agents), which is why content changes should be revision controlled and verified for sanity before merging in most cases. From an REST API stand-point, switching on SSL provides certificate verification, and won''t allow clients who use certificates that are not signed by the CA to connect. However, all clients have such CA''s - so if you want to restrict this you need to set a whitelist in the jetty.ini of your PuppetDB: http://docs.puppetlabs.com/puppetdb/1.1/configure.html#certificate-whitelist In normal circumstances only the puppetmasters should be in such a list, plus any API consumer you may be running internally. Basic local box firewalling or network firewalling of the PuppetDB host is also a good idea. As mentioned though, neither the whitelist or any firewalling constrains the API access to read only access only - a proxy would be better at doing this today however as the API end-points for read and write are quite different (due to our CQRS separation) and should be easy enough to segment.> I also wonder if PuppetDB has any sense of environments? What I mean, does > it separate data in environments, so for example, NODE1 being in development > environment can access NODE2''s resources which is in production environment?No it does not. At the moment you need to provide multiple PuppetDB''s - one for each environment. There is a ticket to provide more environment awareness within queries here: http://projects.puppetlabs.com/issues/17785 But no mention of security constraints around environments. This is an interesting topic though, how would you like to see it work from your perspective? ken. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On Thursday, 14 February 2013 16:37:01 UTC, Ken Barber wrote:> > > My biggest concern is that nodes can access other nodes resources stored > in > > PuppetDB, which effectively means that parameters like passwords and > other > > sensitive information is exposed. > > If the data is not exported this shouldn''t be the case ordinarily. >It actually is the case. For example a file resource does not have to be exported for its content to be stored in puppetdb.> Obviously though if your content is uncontrolled it is possible for > someone to use a function from the puppet master to query data (FYI - > functions run on the puppetmaster, not the agents), which is why > content changes should be revision controlled and verified for sanity > before merging in most cases. > > From an REST API stand-point, switching on SSL provides certificate > verification, and won''t allow clients who use certificates that are > not signed by the CA to connect. However, all clients have such CA''s - > so if you want to restrict this you need to set a whitelist in the > jetty.ini of your PuppetDB: > > > http://docs.puppetlabs.com/puppetdb/1.1/configure.html#certificate-whitelist > > In normal circumstances only the puppetmasters should be in such a > list, plus any API consumer you may be running internally. Basic local > box firewalling or network firewalling of the PuppetDB host is also a > good idea. As mentioned though, neither the whitelist or any > firewalling constrains the API access to read only access only - a > proxy would be better at doing this today however as the API > end-points for read and write are quite different (due to our CQRS > separation) and should be easy enough to segment. > > > I also wonder if PuppetDB has any sense of environments? What I mean, > does > > it separate data in environments, so for example, NODE1 being in > development > > environment can access NODE2''s resources which is in production > environment? > > No it does not. At the moment you need to provide multiple PuppetDB''s > - one for each environment. There is a ticket to provide more > environment awareness within queries here: > > http://projects.puppetlabs.com/issues/17785 > > But no mention of security constraints around environments. > > This is an interesting topic though, how would you like to see it work > from your perspective? > > I think just a simple separation would be sufficient. So that nodes bydefault wouldn''t be able to access data from other environments. I would also be nice to be able easily query PuppetDB API by environment, something like: /v2/<environment>/nodes or /v2/nodes?environment=<environment>.> ken. >Thanks, Vaidas -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
>> > My biggest concern is that nodes can access other nodes resources stored >> > in >> > PuppetDB, which effectively means that parameters like passwords and >> > other >> > sensitive information is exposed. >> >> If the data is not exported this shouldn''t be the case ordinarily. > > > It actually is the case. For example a file resource does not have to be > exported for its content to be stored in puppetdb.Yup agreed ... which is what I was trying to say here, probably not very clearly though: "Obviously though if your content is uncontrolled it is possible for someone to use a function from the puppet master to query data (FYI - functions run on the puppetmaster, not the agents)."> I think just a simple separation would be sufficient. So that nodes by > default wouldn''t be able to access data from other environments. > > I would also be nice to be able easily query PuppetDB API by environment, > something like: /v2/<environment>/nodes or > /v2/nodes?environment=<environment>.So in this case for true separation the puppet master would need to declare to the PuppetDB what environment it is constrained too. Interesting problem, as confining PuppetDB access down to a certificate would then not be enough to constrain this for security purposes, as we don''t hand out per environment Puppet master certificates :-). Today, the way to do it would be - separate puppet master (each with their own certificate) and separate PuppetDB instance, with whitelists only allowing the master on a particular environment to talk to a PuppetDB on the same environment. This may or not be desirable ... but there are other levels of security separation that might deem this necessary beyond PuppetDB. Hiera data is an example of other data one would want to separate (especially hiera-gpg stored data). That is, if one truly wanted to keep environments separate for security reasons - running completely separate hosts/clusters for each environment for this would provide better guarantees to that end, not just at an application level. With each environment maintaining its own CA, master, puppetdb and hiera sources etc. ken. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Thanks Ken. It get your point and it totally makes sense. On 15 February 2013 15:36, Ken Barber <ken@puppetlabs.com> wrote:> >> > My biggest concern is that nodes can access other nodes resources > stored > >> > in > >> > PuppetDB, which effectively means that parameters like passwords and > >> > other > >> > sensitive information is exposed. > >> > >> If the data is not exported this shouldn''t be the case ordinarily. > > > > > > It actually is the case. For example a file resource does not have to be > > exported for its content to be stored in puppetdb. > > Yup agreed ... which is what I was trying to say here, probably not > very clearly though: > > "Obviously though if your content is uncontrolled it is possible for > someone to use a function from the puppet master to query data (FYI - > functions run on the puppetmaster, not the agents)." > > > I think just a simple separation would be sufficient. So that nodes by > > default wouldn''t be able to access data from other environments. > > > > I would also be nice to be able easily query PuppetDB API by environment, > > something like: /v2/<environment>/nodes or > > /v2/nodes?environment=<environment>. > > So in this case for true separation the puppet master would need to > declare to the PuppetDB what environment it is constrained too. > Interesting problem, as confining PuppetDB access down to a > certificate would then not be enough to constrain this for security > purposes, as we don''t hand out per environment Puppet master > certificates :-). > > Today, the way to do it would be - separate puppet master (each with > their own certificate) and separate PuppetDB instance, with whitelists > only allowing the master on a particular environment to talk to a > PuppetDB on the same environment. This may or not be desirable ... but > there are other levels of security separation that might deem this > necessary beyond PuppetDB. Hiera data is an example of other data one > would want to separate (especially hiera-gpg stored data). > > That is, if one truly wanted to keep environments separate for > security reasons - running completely separate hosts/clusters for each > environment for this would provide better guarantees to that end, not > just at an application level. With each environment maintaining its > own CA, master, puppetdb and hiera sources etc. > > ken. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- Vaidas Jablonskis -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.