Puppetizing

The key problem of getting a system up unassisted is that it must acquire a puppet SSL certificate, but puppet doesn't hand those out willy-nilly. Puppet normally requires human intervention on the master (either to sign a certificate request, or to generate a certificate), but this is more hands-on than we want. Instead, we want new systems to start with a piece of secret information, and parlay that into a fresh certificate. Here's how that works:

• The base image starts with a password -- embedded in VM images, where there is no public disclosure of the image itself; or provided at install time for other methods.
• On first startup, the base image runs puppetize.sh, which looks for the password, and then tries to access https://puppet/deploy/getcert.cgi using that password.
• getcert.cgi creates a certificate for the source IP of the HTTPS request, and returns that certificate, the corresponding key, and a trusted CA certificate (in the form of a shell script containing three files) to the client.
• the client installs the files in /var/lib/puppet/ssl and runs puppet.

getcert.cgi also sends an email for every request, so unauthorized certificate creations will be noticed.

See ReleaseEngineering/PuppetAgain/Certificate Chaining for details on how the certificates are generated.

puppetize.sh

puppetize.sh runs on the first boot of new machines, and is responsible for using the deploy password to get puppet certificates (retrying indefinitely) and then running puppet until successful (also indefinitely). When everything is complete, it deletes /root/deploypass.

PuppetAgain keeps ~root/puppetize.sh up to date on client machines, and this script can be used interactively to re-certify a machine when necessary.

Please note that on OS X the first puppet agent call needs the --ssldir=/var/lib/puppet/ssl option added, because certificates are located somewhere else by default.