Reductive Labs – the organization behind the Puppet IT configuration management tools – recently announced that they have received $2 million in funding to “expand the company and further enhance its flagship offering – Puppet”. It’s exciting to see this type of investment and how it will accelerate the development of Puppet.
Part of why its interesting to Tresys and the open source community is because we’ve begun using Puppet as part of the CLIP project to simplify system configuration and lockdown. The way we are using Puppet within CLIP is very exciting and the interest that we’ve gotten from the government security community seems to confirm this.
The goal of CLIP is to transform a vanilla enterprise Linux distribution into a locked down system that meets stringent security requirements including all of the DISA Stigs and the NSS 1253 (which will likely be subsumed by the recently released 800-53 draft). The lockdown is difficult because it requires touching a large portion of the system to tighten file permissions, configure many of the OS security features(such as PAM and the audit system), and set security options on many other applications and services. Previous versions of CLIP did this lockdown using a variety of hand written scripts.
While effective, we were never really happy with the scripts. At a basic level the scripts simply replicated the steps that an admin would do by hand to transform a stock system. They were like a very long, complex recipe: set the permissions on this file, add this line to a configuration file, delete this line from some other configuration file.
It was very difficult to track back all of these obscure, low-level actions to the security requirements because you needed to know not only the action that was being taken but what the system looked like before the action was taken.
This approach also made the configuration scripts very brittle because they depended on the system being in the exact right starting state that the scripts expected. This also meant that the configuration scripts could only be run once and there was no way to check whether a system was properly configured. At the end of the day, this means that creating, customizing, and maintaining a CLIP system was, while dramatically easier than by hand, still too time consuming and difficult.
Puppet takes a fundamentally different approach. Instead of focusing on what low-level steps should be performed, Puppet lets you describe how you want the system to look at a higher level. This makes the puppet configuration clearer and easier to track back to a set of high-level requirements. It puts the focus on the outcome rather than how to achieve that outcome. To actually apply the configuration, Puppet compares the current state of the system to the description of the desired state and automatically figures out what steps need to be performed. This means that you can apply the configuration many times and only the steps that
need to be performed are done. It also means that you can check to see if a system is still configured correctly.
When I first learned about this approach to system configuration I was blown away. In some ways switching the emphasis to describing the outcome instead of how to get there seems like a small change, but the implications are huge. It lets administrators and developers think about the fundamental issue and shifts the tedious and error prone parts of the problem onto smart tools. It’s definitely improving CLIP and our approach to system lockdown.
I’m not the only one excited by the Puppet approach – there is an increase in interest in Puppet from around the globe and across many large and small organizations. The Reductive Labs funding is just a confirmation of the momentum. The time – and therefore cost – savings of using Puppet will continue to drive it’s broader adoption.
