Call with inspec

A file created in this way can then be passed in directly to inspec as a parameter:

inspec exec helloworld_spec.rb

As expected, the test fails. After all, helloworld.txt has the string Helo World! . InSpec is verbose: It not only notes that the test failed but also uses diff to suggest the changes required to pass the test. After making the corresponding change, the problem disappears and calling inspec again reports no errors.

Command Resource

Granted, the above example is not particularly useful. It only checks the content of a single file and looks to see if a certain string occurs. However, in everyday life, admins are responsible for making sure that certain commands run on their systems to verify compliance values.

InSpec uses a command resource for this kind of task that runs various command-line commands and then lets you examine the output of the commands.

In the example in Listing 2, InSpec checks whether the official GPG keys of the Ubuntu FTP teams (Figure 1) are installed on an Ubuntu system: The control, impact, title, and desc directives work here just as they did in the previous example.

01 control "apt-key-1" do
02   impact 1.0
03   title "Is the Ubuntu FTP archive key installed?"
04   desc "Ubuntu cryptographically signs its package lists to verify they are valid."
05   describe command('apt-key list') do
06    its('stdout') { should match /Ubuntu Archive Automatic Signing Key/ }
07   end
08 end

Figure 1: The test checks to see whether the output of apt-key list also contains Ubuntu Archive Automatic Signing Key.

What is again interesting is the part that follows describe (line 5): Using command, InSpec calls apt-key list to check the output on the program's standard output channel for a specific string. Between the slashes is a regular expression that could also be far more complex. Everything allowed in regular expressions is also possible here.

Yet More Resources

The good news is that the syntax of a single test does not change, no matter what condition you link to the respective test. The even better news is that InSpec provides a large number of complete resources that you can use and that come with their own parameters. Resources can be used as needed within the describe block. The InSpec reference manual provides a list [6].

The apt resource is especially interesting on Ubuntu systems: It helps check whether certain repositories are enabled in /etc/apt/sources.list.d in the Apt configuration. In contrast, the iptables resource checks the local iptables rules and alerts you if the rule specified in the test does not exist.

A parse_config resource lets you interpret configuration formats and look for certain values therein. If a specific parser resource does not already exist, mysql_conf, postgresql_conf, and inetd_conf let you browse the configuration files of the respective services.

The package resource is exciting: It looks to see if a specific package is installed and, if so, in what version. Depending on the desired result, InSpec sounds an alarm. Using user and group, you can check in InSpec whether files have the appropriate permissions. The kernel_module resource lets you check whether a particular kernel module is loaded at a given time.

Incidentally, inside the describe block, the syntax of individual tests is very flexible. Because you are not restricted to a single test, you can specify more its lines in each block. Additionally, the should logic can be inverted with should_not instead of should to specify that the defined criterion should not apply.

If you want the alarm bells to ring if a particular package is installed on the target system, you could add:

describe package('tcpwrapper') do
  it {should_not be_installed}
end

If the mentioned tcpwrapper package were installed, the test would fail, and an error message would be visible.

If you get down to work and check various parameters in the form of InSpec tests, sooner or later you will discover that you have compiled a large set of test files that would be difficult to call individually with inspec exec.