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