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

Dan White
Thu, 08 Mar 2012 22:09:21 -0000

I believe this can work with a team.

The team should construct the master manifest/catalog to fit their requirements.
Use techniques that separate the node-specifics from the general catalog -- like
parameterized classes and such.
This master catalog is then locked down and jealously guarded and defended.
The individual nodes are then be built from that catalog for specific purposes.


The configurations that Puppet will lock down are the ones you do not want
developers messing with in the first place.
Any conflict would indicate that the original manifest/catalog needs to be more
flexible/detailed.

That''s my two-cents worth.
I hope it is helpful.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

----- 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"
>
> 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
>
> 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.
>
> 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
>
>
>
>
>
>
> On Mar 8, 7:35 pm, jcbollinger <John.Bollin...@stJude.org> wrote:
> > On Mar 8, 5:43 am, Christophe L <cl.subscript...@gmail.com>
wrote:
> >
> > > Hello,
> >
> > > We are actually evaluating "Puppet Open Source Project"
as the tool
> > > for managing our hosting processes and we have a question about
the
> > > security in Puppet.
> >
> > > As far as we have read, there are only two places where the
security
> > > is taken into account:
> > > - the connection between the server and the client (using
> > >
certificates)http://projects.puppetlabs.com/projects/1/wiki/Certificates_And_Security
> > > - the access to the Puppet Dashboard (using Http basic
authentication
> > > for
exemple)http://docs.puppetlabs.com/dashboard/manual/1.2/configuring.html
> >
> > > Could you tell us if there are other aspects of security in
puppet
> > > that we have not seen please ?
> >
> > That''s an odd way to couch the question.  I presume you have
already
> >
reviewedhttp://projects.puppetlabs.com/projects/1/wiki/Certificates_And_Security
> > ?
> >
> > These general security concerns are relevant to core Puppet:
> >
> > 1) Master and client securely identifying themselves to each other.
> > Puppet relies on SSL for this.
> > 2) Protecting master / client communications from tampering and
> > eavesdropping.  Puppet relies on SSL for this.
> > 3) Protecting the system integrity of the master, and especially of
> > Puppet binaries, manifests, and data.  This is a system-level security
> > concern, outside Puppet''s direct control.  Puppet can manage
security-
> > related configuration on the master when the master is also a client,
> > but the security strategy itself is the responsibility of the system
> > administrator.
> > 4) Protecting the system integrity of Puppet clients.  Much the same
> > as (3), Puppet can be used to help maintain this security, but it has
> > no direct control.
> >
> > > Our first need is to have security on the following main
features:
> > > - add / edit / delete Manifests on the Puppet Master
> > > - add / edit / delete Nodes on the Puppet Master
> > > - add / edit / delete bindings between Manifests and Nodes on the
> > > Puppet Master
> >
> > These issues all fall into my category (3).  Ultimately, if your nodes
> > cannot trust the master then the whole Puppet model is unsuitable for
> > you.  In fact, in that case no centralized configuration management
> > will suit you.
> >
> > One generally relies on the master''s standard security
facilities to
> > protect the binaries and data on the master.  These certainly include
> > the filesystem''s access control features, and they could
include
> > additional security layers such as SELinux.  the bottom line is that
> > protecting the details you mention against unauthorized modification
> > is a matter of protecting files.
> >
> >
> >
> >
> >
> > > The only way we can think about for the moment in order to meet
this
> > > security needs is to:
> > > 1) Have all the configuration of the Puppet Master stored in
> > > Subversion
> > > 2) Define a fine-grained security on the subversion
> > > 3) Prevents all access to the Puppet master by ssh in order to
prevent
> > > manual file changes on the Puppet Master
> > > 4) regularly update the configuration files of puppet from the
> > > subversion
> >
> > > So the whole security would be implemented on subversion, for
> > > exemple:
> > > - a user who is not allowed to commit in the subversion, is not
> > > allowed to change any configuration.
> > > - a user can be allowed to change the manifests, but
won''t be allowed
> > > to change the binding between manifests and nodes
> > > - there will be a branch for each environment (dev, preprod,
prod), so
> > > only specific users will be allowed to change prod manifest,
nodes and
> > > bindings.
> > > - etc.
> >
> > > Is it a good solution ?
> >
> > It is an excellent idea to keep your manifests, data, ENC, etc. in a
> > source control repository.  It is fine to insist that modifications to
> > Puppet''s own configuration proceed via the source control
system
> > instead of being applied directly to the master, but see below.
> >
> > It is a good idea to secure access to the puppetmaster system, just as
> > it is a good idea to secure any server.  Certainly it is best to use a
> > dedicated (possibly virtual) machine as the master, and to disallow
> > non-admin logins by any means.
> >
> > Whether you should cut off all SSH access is a question of just how
> > secure you want to be.  I do not consider allowing SSH access to
> > authorized admins to be much of a risk.  I do rely on my network to
> > prevent external machines from initiating SSH connections to my
> > master, though.
> >
> > HOWEVER, relying on your source control system for file security is
> > not inherently more secure than relying on the master''s
system-level
> > access control features.  In fact, it is probably weaker.  At best, it
> > just changes the target that an attacker must compromise.
> >
> > For controlling and auditing modifications to your Puppet setup in an
> > environment where that setup is maintained and developed by multiple
> > people with different responsibilities, your strategy makes sense.
> > You should recognize, however, that what you propose to secure via
> > Subversion access controls is your development process, not Puppet
> > itself.
> >
> > John
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at