IT compliance is indispensable in both small and large businesses and should be monitored wherever possible. The Chef InSpec open source framework helps admins apply rules on servers in a fully automated process by checking system status against a list of policies and alerting the admin if a system violates them. In this article, I look at setting up and using the software in a practical application.

Chef InSpec comes from a company that feels very much at home in the areas of automation and compliance: Chef, the provider behind the automation platform of the same name. The software is based on its own declarative script language (DSL), a kind of pseudo-programming language. In this language, the administrator describes the rules in a fixed syntax, which InSpec checks later.

InSpec offers the user a few simplifications. For example, it makes available ready-to-use functions for checking certain configuration files or their content (Figure 1), which helps avoid a great deal of manual work. Everyone is familiar with configuration files. They have certain basic formats (e.g., .ini) in which they can be written. The administrator would need to retype the keywords the developers of a program use for their configurations for each service. For this reason, the InSpec developers provide the user with parsers to match a large number of common Unix services out of the box.

Figure 1: InSpec automatically checks the service configurations and the state of the system, as shown here with SSH as an example.

If you have worked with Ansible before, you will notice some similarities with InSpec. Like Ansible, the program expects input files in YAML format. Similar to Ansible playbooks, InSpec profiles offer a way to define rules for certain types of servers and apply them en bloc. The manufacturer offers the program in pre-packaged versions for various systems on its website [1], where you will also find the installation instructions. Granted, Chef has a pretty easy task, because the software is written in the Ruby script language. All you need on the target system is a functional Ruby environment, and that is easy to set up. To check whether the installation has worked, call inspec at the command line. If inspec -v outputs the version number, you are ready to go.

Anatomy of a Profile

The developers have made sure that InSpec profiles can be stored in a version control system. All files of InSpec profiles are written in plain text and can be stored centrally. Therefore, users are advised to work with Git from the very beginning to make it easy to manage the profiles and ensure that a reliable "single source of truth" exists for all profiles in an environment. In this way, errors are easier to identify, roll back, and fix.

The directory structure for an InSpec profile is very simple. In the profiles repository you create the example subdirectory to create a sample profile. In this directory you need at least one file named inspec.yml, which defines the profile. You also need a folder named controls in which all checks performed by the InSpec profile are stored. If desired, a folder named libraries can be added where you establish your own resources. If the profile requires additional files, they end up in a different folder named files.

A file named README.md should explain the functionality of the profile you create. It is especially useful if you want to share it on GitHub. The format should be in the GitHub flavor of markdown. However, if you can do without special formatting, simply add plain text to this file.

A Simple Example

The structure of an InSpec profile can be better understood by looking at a simple example. If you need to display a notice with the General Data Protection Regulation (GDPR) to every user on the desktop for compliance reasons, the best way to do this is to use the /etc/motd file. This file is automatically displayed by the system when each user logs in. The file function is suitable, because it can search for specific content in text files with the keyword content. To ensure that the GDPR string occurs in /etc/motd, you have to combine the contains keyword with a regular expression:

describe file('/etc/postgresql/9.1/main/pg_hba.conf') do its('content') { should match /Please observe the GDPR regulations/ }

This control checks the entire content of the /etc/motd file for the described string. If InSpec finds the entry, the system is considered "compliant" for this control. The statement described does not yet constitute a complete control in itself because, in addition to the tests, a control also contains metadata. At the beginning, you have to specify at least a name with the syntax

control <Name> do

and add the end entry at the end. If you leave out the metadata, InSpec complains about the missing entry in /etc/motd. However, because the impact keyword is not set, this does not set off the alarm bells. You can change this behavior by inserting a block with the following syntax immediately after the control line and before describe:

impact 'critical' title 'Verify GDPR hint exists in /etc/motd' desc 'Control tests MOTD for GDPR hint and sends out alarm if missing' tag 'gdpr'

The first InSpec test is now defined. You can save it (e.g., as dsgvo.rb) in the controls folder of the profile currently in use. By the same principle, you can create any number of additional files with checks in the same folder. Once the controls for a profile are ready, the next step is to create the inspec.yml file, which turns the controls into a standards-compatible profile (Listing 1).

name: profile
name: profile
title: InSpec profile to check /etc/motd
maintainer: Martin Gerhard Loschwitz
copyright: Hutchison Drei Austria GmbH
copyright_email: martin.loschwitz@drei.com
license: Apache-2.0
summary: Tests whether the string "DSGVO" appears in MOTD
version: 1.0.0

Applying the Profile

The final step in creating the profile is to apply it to a system. To begin, copy the entire profile to a target system and run

inspec exec <profile folder>

or use InSpec's SSH capabilities, which may be the better approach,

inspec exec Example --key-files $HOME/.ssh/id_rsa --target ssh://root@10.42.0.1

especially for large environments.