How Puppet’s automated configuration management keeps you secure
One of Puppet’s core features is its ability to maintain your infrastructure in exactly the state you define for it. Describe the configurations you want in a Puppet manifest just one time, and Puppet will apply and maintain those settings for as long as you wish.
This ability to automate configuration management offers you significant advantages when it comes to security, because automated configuration management lets you broadly enforce system rules, plus get an automatically generated audit trail so you can report on compliance.
This only works, however, for resources you manage with Puppet. What happens if you need to make sure that none of your nodes are running a vulnerable package, and you manage that particular package on only a portion of the affected nodes? For all its power, Puppet cannot maintain enforcement of a configuration on any package that you haven't explicitly told Puppet to manage.
Puppet can, however, report on these packages, as long as a Puppet agent is installed on the node hosting the package. In this blog post, I’ll show you how Puppet Enterprise’s reporting tools can help you track and manage package vulnerabilities, even on nodes where you aren’t managing the vulnerable package with Puppet.
Imagine that you have the openssh-server package on a set of Ubuntu servers. Say that you already have a Puppet manifest that includes a class to ensure that you run version 1:6.6p1-2ubuntu2.6 of the package on some of these nodes. For the sake of this post, let’s say you’ve just learned that version 1:6.6p1-2ubuntu2.7 patches a vulnerability that's present on the version you’re using.
You can modify the class like this:
When Puppet runs on these nodes again, it will update the openssh-server package version to 1:6.6p1-2ubuntu2.7, and your vulnerability will be patched.
Of course, that package version can still be changed manually on individual systems. For example, a developer in your org may have been using version 1:6.6p1-2ubuntu2.6, unaware that it poses a security risk. The developer sees the change you made with Puppet, and uses
apt-get to roll back to the version they prefer, on their machine only.
Puppet will fix that. On its next run, Puppet will see version 1:6.6p1-2ubuntu2.6, and change it back to 1:6.6p1-2ubuntu2.7 — the version you indicated in your manifest. You’ll see a corrective change report, so you’ll know that someone manually altered the approved configuration, and that Puppet corrected their change. In this way, you can be confident that your systems and data are protected, and you also have an opportunity to tell people in your organization, "Hey, don't manually change back to version 1:6.6p1-2ubuntu2.6 — it contains a vulnerability."
Before we continue, it might be useful to briefly review the types of change reported by Puppet.
Intentional changes are any changes that you make yourself, in your Puppet code. Remember that Puppet uses your code as its instructions for how you want your systems to look.
Corrective changes are those Puppet itself makes when it finds that a configuration setting on a system does not match the setting you defined for it in your Puppet code. That is, Puppet corrects configuration settings to match the instructions you have given it.
Puppet will always correct back to your desired version, and report that correction. So you get full situational awareness, and, via Puppet's reports, an audit trail to prove compliance.
What if you notice a pattern of corrective change to the same resource, and you can’t track it to someone in your organization? You may have an active security issue.
To track changes after Puppet makes them, use the Puppet Enterprise console. You can view all changes, both intentional and corrective, all the way from the most recent run for each node you manage (both in enforcement and simulation — or “no-op” — mode) to runs that occurred up to two weeks ago (or even longer, if you customize your report settings).
View corrective changes
In the example above, one node shows corrective change. You can click straight through to view the report for the most recent run, a history of reports for the node, and details on the change itself, to help you understand the manual change Puppet corrected, and why.
View change detail
Puppet Enterprise console reporting tools — run reports, logs, catalog visualization and event inspection — help you to quickly zoom from a high-level view of overall infrastructure health down to a deep dive into a single event. You can discover what changes occurred in your approved configuration, when they occurred and whether they form a pattern of change that you need to investigate further.
Finally, let’s step back to those nodes on which you’ve installed a Puppet agent, but where you haven’t chosen to manage the openssl-server package. Even if Puppet cannot correct this manual change (because it has no instructions from you to do so) it will still report on the package’s existence by all versions present, and allow you to quickly discover nodes where the vulnerable version exists.
From there, you can either manually reconfigure them, or you can prepare to bring the package under Puppet management, so you don't have to worry about it ever again.
Verne Lindner is a senior user-experience architect at Puppet.