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 <[email protected]> wrote: > On Mar 8, 1:12 pm, Christophe L <[email protected]> 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 [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.
