On Mar 8, 5:43 am, Christophe L <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
