limited access to specific files on master server

[Patrick Viet]

Hello,

I am new with puppet software, so please indulge my simplistic
question. I have looked through the FAQ and not found anything about
this.

Here is the context : I work for a hosting provider, that has several
dedicated customers, and manages sometimes specific configurations for
different customers. As an example, for each customer there is a
particular /etc/hosts.allow file that allows a list of IP addresses to
access the servers.

This kind of list is confidential information, and I wouldn't like
another one customer to be able to access another customer's
hosts.allow file.

My question is : can puppet limit the access to certain files - stored
on the puppet master - to only some specific servers or group of
servers ? Same goes for the puppet declarative configuration files
(called 'manifest' I believe) : I wouldn't want one customer to be
able to read the special manifests of another customer...


Thanks for your insights.

Patrick

[Larry Ludwig]

Puppet's security model is very flat and simple.

You have a few options I can think of quickly:
- a separate puppetmaster per client (not feasible IMHO)
- pass the sensitive data as puppet variables and use erb files
- create unique keys for each server that way the (UUID ?) to make it
not obvious how to reference a specific puppet URL.
- store the configuration files outside of puppet and use puppet to
retrieve the files via some external method.

The same security also applies to storing file changes on the
puppetmaster.

-L

--
Larry Ludwig
Empowering Media
1-866-792-0489 x600
Managed and Unmanaged Xen VPSes
http://www.hostcube.com/

[AJ]

You can kind of achieve this with multiple file server mountpoints
ACLing different ranges/DNS.

There is no arbitrary way for a Puppet client to get at files served
by the master (no index, etc) so not really sure this is an issue..

Only files in the compiled manifest are managed.

The compiled, node scoped, manifest is only ever served to the
relevant authenticated, named node so also not really an issue

[Ohad Levy]

Hi,

 

I would consider using environments, you could then share some modules (reuse) which have no confidential information in, and what ever is confidential use modules which would exists only in one customer environments.

 

the only thing that you would probably need to do is have a check if a client is allowed to use a certain environment, that could be done easily by checking the domain name or something similar.

 

Ohad

[Jeroen van Meeuwen (GMail)]

Larry Ludwig wrote:
> Puppet's security model is very flat and simple.
>
> You have a few options I can think of quickly:
> - a separate puppetmaster per client (not feasible IMHO)
> - pass the sensitive data as puppet variables and use erb files
> - create unique keys for each server that way the (UUID ?) to make it
> not obvious how to reference a specific puppet URL.
> - store the configuration files outside of puppet and use puppet to
> retrieve the files via some external method.
>

Another model that I've been exploring is creating one share, say
private/, and having the manifests use facts (which cannot be
reassigned, in my case I use $domain) to create specific trees.

A source would then be: puppet:///private/$domain/foo/bar

Prerequisites to this model, however, is that:

1) The domain fact is equal to what is in the CN of the certificate, and
2) you do not use autosign

Another model is to let the client clone a repository from a location
and refer to these local files, and apply access control on the location
where the repository is pulled from (or, refer to source control
management system from puppet directly, requiring the scm to be
integrated which I think is the case for CVS??).

Kind regards,

Jeroen van Meeuwen
-kanarip

[zoniguana]

Another option:
Store the files on the puppetmaster as, e.g., hosts.allow.host1;
hosts.allow.host2.
Set the permissions of those files to 0400, owned by user puppet,
group puppet.
Then regular users logging on to the puppetmaster server cannot read
them (Though really, regular users shouldn't have access to the
puppetmaster anyway, but....)
Then, each puppet client can pull down its own respective files, by
having it pull down hosts.allow.$hostname.

On Sep 2, 7:43 pm, Patrick Viet <patrick.v...@gmail.com> wrote: