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