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

jcbollinger
Thu, 08 Mar 2012 15:35:42 -0000

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
reviewed
http://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