On Friday, May 11, 2012 5:56:10 AM UTC-7, Marc Zampetti wrote: > > Does this require that a human being has to be in the loop every time a > node joins the site? How would one automate 100% the provisioning of new > hosts? With the current system, I can turn on auto-sign and have some > simple rules for which nodes I will accept, and trust in the knowledge that > I have already ensured my network is secure enough to accept the risk of > auto-signing. With that, I can automatically take a bare-metal server, and > provision it all the way up to taking traffic without having anyone else > involved. From the example above, having to generate the key on the master > before I can provision puppet on the node seems to make that much more > difficult. >
We don't want Puppet admins to have to trust that their network is secure. What Puppet Sites provides (among other things) is a PSK system that allows you to generate multiple-use keys for securely joining nodes to your site. In the provisioning case, you could generate a pre-shared key, bake it into your install tarball, and use that tarball to install Puppet and add each node to your site without human intervention. When you're done installing, you can revoke the PSK so it can't be used anymore. This gets you the convenience of autosigning with the confidence that even if your network is compromised, your Puppet deployment won't be. But note that you can still use autosigning if you don't want to mess with pre-shared keys, or if you trust your network. We're just providing an alternative, not a replacement. If you want to manually execute `puppet site accept` for each node that tries to join your site, you can do that too. > Also, it would be good if you specify the issues that Sites is trying to > solve in more detail. From my viewpoint, I don't have any issues with the > current CA-based model. So I'm struggling to understand what you are trying > to "fix". I'm sure I'm not alone, and I am assuming that I missing some > details, so putting a more detailed description of the problems that the > community is encountering, and how Sites would solve those would help with > the discussion. One problem is that there isn't an authoritative source of information about which nodes are in your deployment. The CA comes close, but since you can remove the certificates of managed nodes, it doesn't fit the bill. That's one thing that Puppet Sites gets you. The ability to run a single command and know with certainty which nodes you're managing. Another problem is that if you move services around, you have to update puppet.conf on all nodes that use that service. For example, if you migrate your master to a new host, you have to update puppet.conf on every agent that uses that master. What Puppet Sites provides is a service registry that allows you to store this information in a central location. Your agents retrieve service connection information from the service registry. So, if your master switches to a different host, all you need do is update the host in the service registry, and all your agents will pick up that change automatically. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/d-aNxTfDTSYJ. 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.
