Puppet users - Mar 2012 - Puppet and the security on nodes, configurations, etc.

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 ?

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

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 ?

Is there a better solution in order to restrict access as described
below please ?

Thanks in advance for your answers

Best regards,
Christophe

-- 
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
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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
http://groups.google.com/group/puppet-users?hl=en.

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
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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
http://groups.google.com/group/puppet-users?hl=en.

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
http://groups.google.com/group/puppet-users?hl=en.
> 
-- 
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
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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
http://groups.google.com/group/puppet-users?hl=en.

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
-- 
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
http://groups.google.com/group/puppet-users?hl=en.