How Automated Configuration Management Works in Puppet

Automated configuration management comes with many benefits — especially if you use Puppet. Get an overview in this blog.

What is Automated Configuration Management?

Automated configuration management is the process of using automation to describe your configurations once and let automation apply and maintain those settings.

Adding powerful state-enforcing automation to your configuration management system saves time and effort. Automated configuration management reduces the time it takes to scan for configuration errors, remediate them, and enforce configuration baselines to prevent drift.

Why Automate Configuration Management with Puppet?

You should automate configuration management with Puppet to gain significant advantages when it comes to security. 

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 through configuration management tools offers you significant advantages when it comes to security. Automated configuration management lets you broadly enforce system rules, plus get an automatically generated audit trail so you can report on compliance.

How Puppet Automated Configuration Management Works

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:

package { 'openssh-server':
  ensure => ‘1:6.6p1-2ubuntu2.7’,
}

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."

🔏 Policy as Code eBook It's like IaC for compliance: Write your configurations as code and PaC will keep them where you want them – automatically. Learn more with our free eBook. DISCOVER POLICY AS CODE

Reporting on Configuration Changes

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.

Get Started With Puppet Automated Configuration Management 

See for yourself how Puppet Enterprise can help you with automated configuration management. Start your free trial today. 

START MY TRIAL

Learn More

• How to use Puppet to simplify IT automation 
• Download: How to Modernize Your Change Management with Enterprise DevOps
• Class containment in Puppet Enterprise: What it is and why it matters
• How Red Hat Satellite + Puppet can coexist to support configuration management

This blog was originally published on July 20, 2017 and has since been updated for accuracy and relevance.