Some time ago, I wrote about Environment Leakage, and I'm happy to report that this is much less of a problem today. As of Puppet 4.8 and Puppet Enterprise 2016.5, most custom types will no longer be subject to environment leakage. It's transparent for the end user, when Puppet Enterprise Code Manager is configured, and can be used in Puppet Open Source by following the documentation.
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