If you've used Puppet for anything non-trivial, you've almost certainly used it to configure something secret. Perhaps you've configured an application with a database password. Perhaps you've configured a local maintenance user account with a private SSH key. Something that might seem obvious in retrospect is that these secrets exist in the catalog--and by extension all reports and any other tooling that uses them. Anyone with access to the catalog or raw reports also has access to your secrets. All your secrets.
You may have read some docs, or stopped by the #puppet IRC channel. You've likely read a blog post or two. You've probably run across the word idempotence or have been chastised for writing non-idempotent Puppet code with
exec resources. But what exactly does that mean? Here's a definition that you might see in a calculus class.
Welcome back; gather 'round. Today we're going to talk about a topic we've all been wondering how to bring up. We'll be talking about leakage--no, not that kind of leakage! (Those of you too young to get that joke are highly encouraged to not go look up the history of Olestra.)
Update: In many cases, environments no longer leak on Puppet 4.8 and above.
So now we've used Puppet to manage a file on our computer. The
/etc/motd file is now owned by root and has a fun little sentence in it. We can write all we want out to that file. But sooner or later, we're going to want to put something a little more interesting. Perhaps we'll want the hostname or operating system installed?
We'll take a little side trip first, though, and learn about
Configuration management with tools like Puppet can make your life a lot easier. It can make configuring newly provisioned servers more repeatable and reliable and it can make disaster recovery nearly trivial. Learning to use the tool isn't trivial by any means, though. There are 200 configurable options, give or take depending on the version you're running, and the number of things you can do with it is nearly infinite.