Re: [Puppet Users] Re: Puppet and the security on nodes, configurations, etc.

Richard Clark
Thu, 08 Mar 2012 19:48:58 -0000

On 8 Mar 2012, at 19:13, Christophe L <cl.subscription@gmail.com> wrote:

> Hello,
>
> Thank you very much for your answer !
>
> We will look into your approach.
>
> I understand what you explained but I''m a bit surprised by this
> approach.
> Let''s say you have a small team for managing the whole
infrastructure,
> the approach you described seems to be quite relevant.
> In our scenario, we have a team of around 20 persons (growing up),
> with different roles, and hundreds of VMs and servers, some of them
> being critical (so with very restrictive access).
>
> Having puppet as our central configuration management tool would mean
> that every one would need to modify the elements of the infrastructure
> he is responsible for in the central repository.
>
> We can easily imagine that a trainee won''t be allowed to change or
> even look at any production configuration for example.
>
> So what we would like to have is the ability to define "who" is
> allowed to see/edit/delete "what"

Via your RCS - most people use git these days, but SVN should suffice
- you''d use ACLs based on path or branch. Rather than allowing SSH
access to all, just have a post-commit hook that does an ''svn
up'' or
''git pull'' on the puppet master when someone commits to the
repository. If the user doesn''t have rights to that path/branch then
they can''t commit.

You can have a workflow where junior admins have their own fork for
development, but merges into production repos have to be signed off
and completed via by a senior admin.

Recommend storing modules in standalone repositories and using
svn:externals/git submodules.

Also - keep any sensitive data outside of your repositories and use
Hiera to pull it in where needed. That way you don''t have to worry so
much about your junior admins seeing something that they shouldn''t and
you can give them read access to the whole repo(s).

>
> It is a typical scenario for an hosting company isn''t it ?
>
> Using the filesystem permission in order to implement that would mean
> that everyone is allowed to access the puppet master Through ssh:
i''m
> not sure our security administrator will agree on that.
>
> If it''s a matter of file permissions, we could too define FTP
accounts
> with restricted access I guess ? But that''s almost the same thing,
> everyone will need to access the puppet master on port 21

FTP? is it 1996 already?

>
> Moreover, it is not only for developpement since node definitions
> needs to be define and are different between each environment
> (development, preproduction and production), and node definitions is
> what is specific to every customer.

For deployments of more than 30 or so nodes, use an ENC for defining
and classifying nodes. Far easier to manage and automate.

>
> So, I think that when a central configuration management tool is used,
> there is a strong need on authorization system.
>
> We thought about subversion, but I guess there are better solutions.
>
> Could you please tell me if I''m thinking the wrong way, or if our
> needs doesn''t match the use of a central repository, or if I have
some
> misunderstandings about puppet and its purposes please ?
>
> Thanks in advance for your answer.
>
> Best regards,
> Christophe
>
>
>
>
>

Cheers,
--
Richard Clark
richard@fohnet.co.uk