« Previous 1 2 3 4 Next »
Automated compliance testing with InSpec
Strictly Managed
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.
Listing 2
Verify FTP Key Installed
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
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
.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)