Moving Beyond the Limits of Infrastructure Testing with Chef InSpec 2.0

Feb 26th, 2018 9:37am by Dominik Richter

Dominik is a founder, product leader, and engineering manager who co-created InSpec, Chef Compliance, and the dev-sec.io project. His company VulcanoSec was acquired by Chef Software and drives its security and compliance solution. He has 15 years of experience in engineering, hacking, and leading successful teams.

InSpec just reached its next major upgrade with the release of InSpec 2.0. After more than two years as an open source project and a year since its last major release, it has grown considerably in scope, stability and community.

This release adds over 30 new resources, major performance improvements, bug fixes and stability since InSpec 1.0. However, the seemingly innocent addition of Amazon Web Services and Azure support points to a major shift in the foundation of InSpec itself.

In this article we will look at the beginnings of operating system (OS) and server testing and how InSpec expanded to go from simple node verification to the promise of covering your entire computing fleet. InSpec 2.0 quietly opens the doors to a new world of automation and security testing that unifies different systems and exposes them at your fingertips.

Train for the OS

InSpec was inspired by Serverspec, a framework for server testing. As such, it is perfectly suited to test operating systems and node configurations and services.

InSpec is built on top of train, the transport interface — a type of API that talks to operating systems locally and remotely. Train allows InSpec to provide resources without dealing with all the details of OS detection and handling.

Going Beyond the OS

When we first deployed InSpec in larger real-world use-cases, we started noticing tests for databases and API endpoints. While InSpec itself didn’t prevent us from adding these, it led to a number of shortcomings we couldn’t solve:

Profiles would report on the operating system they ran on instead of the component they were verifying. For example, you would test an AWS API but the report would indicate that the test ran on node xyz for a RedHat Linux box. We want InSpec to report on the actual target instead of the current execution environment.
Profiles that were written for APIs could not test if they were targeting the right system. For example, a profile can indicate that it only supports Windows Server 2012R2 and won’t run on Linux. API endpoints embedded in code wouldn’t allow these checks to run.
Resources could not indicate that they were written for an API-based target. For example, an aws_iam_role will only work on AWS. To verify this before executing the profile, we need to know that the user wants to test AWS.

We could have easily stopped here and decided to create another tool for testing API endpoints. Ultimately, we decided against it because we saw InSpec moving to test complete infrastructure fleets and we realized we were falling short of this goal.

Of course, a simple remedy could have also been to just Frankenstein API support into the current execution layer of InSpec. However, the confusion this idea caused in early discussions quickly determined its fate.

Platform Support in InSpec 2.0

We decided to expand InSpec’s horizon from the OS to a broader range of platforms. Operating systems, in this model, make up one branch of targets. API endpoints are another, specialized in low-level sockets (TCP/UDP), mid-level targets (HTTP/REST) and high-level APIs (AWS, Azure). Remote connections to databases and network devices are easily supported in this model.

With the release of InSpec 2.0, our wonderful team and community finally reached its lofty goal. The RFC, which had been brewing for a year, finally met its implementation. InSpec has now opened its gates to full-stack testing of infrastructure fleets beyond operating systems to all other components that are included.

This release not only adds AWS and Azure support but also enables us to easily other components to expand this framework to the evolving landscape of your computing fleet.

InSpec Update Stability

InSpec’s 2.0 release also demonstrates an important aspect of our update philosophy. We aim to keep the amount of breaking changes at a minimum and make upgrading to another major version as easy as possible. It may appear like a huge update moving to this version, but if you have been upgrading regularly, it really isn’t.

Using a roll-forward approach, we have introduced most 2.0 changes to the stable 1.x codebase during the development without breaking compatibility. All breaking changes have been collected in a separate issue and are mostly in the shape of deprecations that will be removed with the upgrade. If you run InSpec without any deprecation warnings today, you are safe to move forward.

Huge thanks to the team and the entire community that has been driving this release of InSpec! I’m looking forward to the future of this project.

Chef is a sponsor of The New Stack.

Dominik is a founder, product leader, and engineering manager who co-created InSpec, Chef Compliance, and the dev-sec.io project. His company VulcanoSec was acquired by Chef Software and drives its security and compliance solution. He has 15 years of experience in...