Developer Automation Tools Bootcamp

Learning about development tools and automation

View project onGitHub

Introduction to InSpec



InSpec is an Auditing and Testing Framework from Chef.

You are probably familiar with Chef providing tools to configure your machines. InSpec is a new tool extending the scope where Chef can watch over your machines for their entire lifecycle. The use of InSpec does not require a Chef Server or the Chef Client. InSpec is focused on proving your systems are in an expected state through compliance as code.

This can mean a user account exists on the machine, certain rules for password requirements are being met, services are running as expected and more.

Going beyond ServerSpec

InSpec shares its roots with another tool, ServerSpec, which is also a Ruby RSpec based testing framework. There are two key differentiators from ServerSpec that I appreciate the most.

First up - InSpec has connection protocols built-in which allow it to talk directly to remote systems over SSH, WinRM or to Docker containers. These transports allows you to have a central machine watching over your flock of machines. If you are really interested in this type of setup, Chef has a commercial offering called the Compliance Server. It is a powerful ally to running your InSpec tests, but is not required to run your InSpec tests. You can achieve the same core functionality by having a Jenkins job execute InSpec against various remote machines, but you would be on your own to generate the resulting alerts and reports.

Secondly, InSpec allows you to give each control group you create an impact score to weigh the importance of the rules you are writing. Having telnet enabled can be ranked as a show stopper. But unexpected contents in your application's configuration file could only raise a warning. Using the impact score to improve your signal to noise ratio of the alerts being raised can be an invaluable gain.

Always be testing

You don't want your machines to be in compliance just at the moment they are turned on and initially configured. You *need* your machines to always be compliant. Depending on your business needs this can mean validation once a day, once a week or once every 15 minutes. The more frequently you validate your machines, the quicker you can identify what (and hopefully correspondingly who) changed the system. I recommend scanning them as frequently as is possible and useful to you.

Standard Tests

The work you do probably is goverened by some standard compliance rules like following Center for Internet Security (CIS) benchmark or Payment Card Industry (PCI) compliance rules. These are standard tests and users are posting shared compliance profiles to the Chef Supermarket. Look for this list to grow with time.

Summary

Combining InSpec in to your development workflow and production monitoring will give you the benefit of ensuring your machines are in a consistent state of being. More importantly - any future changes to your machines will maintain consistent state or raise an alert. A quick fingered admin who likes to get directly on machines and update configurations can be kept in check by InSpec with quick alerts after their changes have brought a machine out of compliance.

Workout

We are going to complete the following actions

  1. InSpec is installed on our trusty VM. It acutally comes bundled in the Chef DK, which is how it was installed on our class VM.
  2. We're going to execute the example OS Hardening profile against our class VM.
  3. We can pull the most up to date Inspec profiles directly from GitHub and exec it against our VM by running inspec exec https://github.com/dev-sec/linux-baseline
  4. The results will tell us how well I did making a hardened OS for the class VM. ***Spoiler Alert*** I didn't make any efforts to do this.
  5. But, we can use same profile against one of our Docker containers from the Artifactory workout. An example of using InSpec with the docker:// transport is in the InSpec README.
  6. First, let's make sure we can connect to the container. We know the name of our container is artifactory and make the command inspec detect -t docker://artifactory and what do we learn about it? (If this fails, go back and docker run the Artifactory container from earlier.)
  7. Now we can do our scan with a inspec exec tests-os-hardening -t docker://artifactory.
  8. The results say? Who released the more hardened OS image?
  9. Next - we will check the path level of the Artifactory container and the class VM.
  10. inspec exec https://github.com/dev-sec/linux-patch-baseline -t docker://artifactory
  11. inspec exec https://github.com/dev-sec/linux-patch-baseline
  12. Finally - go find a profile that is relevant to the work you do and scan one of your own machines! :yikes: