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

Christophe L
Sat, 10 Mar 2012 13:11:12 -0000

Hello,

Thank you all for your feedbacks !

Being new to DevOps field, I''m doing my best to understand the
concepts and concerns of this field, such as security, and you have
been quite helpful on that.

I will go for a secured subversion + ENC approach and secure the
filesystem so that no manual changes can be done but through the
subversion pulling.

Thanks for your help.

Best regards,
Christophe


On 9 mar, 18:14, jcbollinger <John.Bollin...@stJude.org>
wrote:
> 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