Re: PuppetDB API permissions

[Nick Lewis]

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)?

[ak0ska]

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.

[Vaidas Jablonskis]

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

[Erik Dalén]

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

--
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...@googlegroups.com.

To post to this group, send email to puppet...@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

[Ken Barber]

> 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.

[Vaidas Jablonskis]

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.

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>.

 

ken.

Thanks,

Vaidas

[Ken Barber]

>> > 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.

[Vaidas Jablonskis]

Thanks Ken. It get your point and it totally makes sense.

--
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...@googlegroups.com.
To post to this group, send email to puppet...@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