On Fri, Mar 26, 2010 at 12:22 AM, Daniel Pittman <dan...@rimspace.net> wrote: > G'day. > > One of the current problems we face with our puppet network, and about which > I would like to solicit opinions, is the distribution of secret keys for > (mostly) SSL secured services. > > The most pressing example of this is that for reasons of availability want to > process SSL on multiple machines for a single certificate. The same issue > applies to a wide range of internal and public services, though, where we need > to distribute key material.[1] > > > The prospect of putting the secret key into our revision control system has > ... well, little appeal is probably being fair: we could certainly do it, but > it suddenly means that a whole bunch of extra data has to be treated as high > security rather than low security.[2]
What about keeping encrypted versions of the key in your revision control system, and then writing a function for the puppet servers that decrypts them using a key that you need to distribute out of band to your puppet servers? You'd still be sending the unencrypted data across, but this should be a secured connection, and it will end up in your client catalogs, but they should be protected just as much as the data on the client disk would be. > > > On the other hand, it would be good if a trusted agent like puppet can be > configured to automatically bring up nodes that run secure services from > scratch with no human intervention involved. That helps with availability, > as well as security issues like key rollover. > > > On the gripping hand, I mistrust human involvement: if I have to give *people* > (including me) access to the key material, rather than software, I have a > whole set of less trustworthy and reliable agents handling it. > > > So, on the whole my feeling is that an automatic "key distribution service" > that was accessible to puppet but (mostly) not to people would be ideal. > > I also feel that it would be ideal to keep that service distinct from our > standard puppet Subversion repository, to keep the need for security > boundaries small. > > > I am interested here in other views on my assessment of the problem, and in > pointers to practical tools used to solve the problem. > > Daniel > > Oh, and at the moment I am considering the puppet client/server protocol > trustworthy enough to enforce access control to the key material. :) > > > Footnotes: > [1] Generally, key material where we don't require a passphrase to unlock > before use, because we have made the availability/security decision based > on our business needs. > > [2] ...well, technically "medium grade" security, since at present reading > our puppet manifests is worth little to an attacker, but writing to them > is valuable. So, we protect writes heavily but don't worry too much > about, for example, a backup of the VCS repository they live in. > > -- > ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707 > ♽ made with 100 percent post-consumer electrons > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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. > > -- nigel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
