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

jcbollinger
Fri, 09 Mar 2012 14:14:25 -0000

On Mar 8, 1:12 pm, Christophe L <cl.subscript...@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.


If you think I recommended for or against any particular approach then
you should re-read my comments.  All I did was describe the security
concerns surrounding Puppet, as I see them.  I included a few comments
about my own security choices for my environment, but those are
qualified by a disclaimer that what''s best for you depends on how
secure you want to be.


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


You have clearly mistaken me.  I never said that you should rely
exclusively on filesystem permissions, mandatory access controls
(SELinux), or other security measures local to the master.  I said
that you *could*, and that the security implications *with respect to
Puppet* would be at worst equivalent to the security implications of
using a source repository to buffer configuration changes.  You anyway
do rely on the master''s permissions in the event that the master is
compromised, so you must not ignore that aspect.

You must not overlook, however, that if the master periodically pulls
down the latest manifests from the repository, then you just move the
main burden for authorization and access control to the source control
system.  That in itself doesn''t make security any better -- in fact,
the result is slightly weaker because there are then more points of
possible compromise.  It may serve your purposes better in other ways,
however.


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


Node definitions are either in your manifests or in your ENC.  The
security considerations are pretty much the same for them as for the
rest of your manifests.


> So, I think that when a central configuration management tool is used,
> there is a strong need on authorization system.


I never said differently.


> We thought about subversion, but I guess there are better solutions.


I use Subversion to track my manifests, but more for the traditional
purpose of tracking modification history and supporting rollback.  A
lot of people in the community prefer git.


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


No one here can tell you what''s right for you.  Furthermore, it sounds
like you may not have worked out your security scenarios in much
detail, and that may make it difficult for *you* to determine what''s
right for you.  Nevertheless, a number of folks around here use setups
similar to the one you describe, and to be satisfied with them for
their own purposes.


John