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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
