Implement compliance-as-code with this Chef InSpec tutorial
Chef InSpec is one of many tools IT admins can use to ensure applications and infrastructure are in line with their company's unique security and compliance needs.
Specifically, Chef InSpec supports compliance as code: The tool runs automatic tests, or scans, to determine if a package or folder is in its desired state on a target machine. Rather than change that state to meet the conditions of a Chef recipe, InSpec generates a report similar to a unit testing framework's pass/fail report. Another IT process then ingests that data to bring the device in question back into compliance, or to simply identify machines that are out of compliance so IT admins can take further action in a different way.
In this Chef InSpec video tutorial -- which reviews must-know commands and features two example tests -- we run InSpec version 4.18.104 on Ubuntu 20.04, but the software can be downloaded onto any Chef-supported OS.
Helpful Chef InSpec commands
Once InSpec is installed, run the inspec version command from the terminal to validate that it was installed correctly. To see a full list of InSpec commands, run the inspec help command. Admins can also issue this command to see syntax and example usage for a specific command. For example, to learn more about the inspec exec command, run inspec help exec.
It's important to validate that InSpec can gather information about the target OS. To get OS details, run the inspec detect command, which will return the name, release version and architecture of the target OS.
Run compliance tests
The inspec shell command enables admins to define and try tests interactively, as well as look at the properties available from each resource.
The syntax to run Chef InSpec tests is:
inspec exec <Directory_to_inspec_module>
Tests to define Chef InSpec resources are kept in Ruby files in the controls folder in the code directory. These resources can be in the same file or different files to simplify versioning. The inspec exec command will run any resources under that folder in the directory passed to the command. As shown in this Chef InSpec tutorial video, resources are defined similarly to the one below, which checks if the Nginx package is installed:
```
describe package('nginx') do
it { should be_installed }
end
```
The first line in the describe block defines an InSpec resource. To check for a directory resource instead of a package resource, replace the package() descriptor with a file() descriptor. There is a complete list of supported resources in the InSpec documentation.
On the second line in the block above, the should keyword is called an expectation, which represents the expected value or state of a resource, and the be_installed keyword is a matcher, which compares actual resource values to the expected value. While there are several InSpec matchers to allow for different conditions, there are only two expectations: should, which refers to something that is expected to be present, and should_not, which refers to something that is expected to be absent.
Finally, admins can run any Chef InSpec command on a remote server using SSH. The video demonstrates this by running the same package on a remote server using the -t parameter to specify the remote server and the -i parameter to specify the SSH key file required to access the server. It's worth noting that the remote server shown in this Chef InSpec tutorial did not have any Chef products installed; it's possible to use InSpec on existing infrastructure without deploying a separate remote agent across the environment.
Hello, and welcome to this demo for Chef InSpec.
So, the first thing I'm going to do is take a look at the code I'll be showing off today. I'm in the inspec_demo folder, and here I've got these files. The three that I want to draw your attention to are the controls files -- and these are just Ruby files that we're going to dive into in just a minute -- and a .pem file. There are two other InSpec files here, and those are just for profile purposes, in case you wanted to put this in the cookbook. So, for now, let's skip those and take a look at the files I have under the controls folder.
These are two Ruby files -- which Chef runs under Ruby for those who don't know -- and the first one is nginx.rb. It is a test to see if the package nginx is installed -- and it should be installed, per line two. And then the second one is a describe file on the tmp directory under the root folder. So that should be present, and it should be a directory. Let's check both of those manually first, starting with the tmp directory. So, we do see we have a directory under my root folder called tmp. Let's check for nginx now. So, we see we do have two packages that fit that gin string, but neither of them are nginx. Let's see what happens now when we run Chef InSpec. And the last argument we're going to pass in -- in case it's not visible enough on the screen -- is just a dot [.], to make it run in the folder we're currently in, which has the controls folder in there. Great.
So, we see that the tmp directory is there -- that test passed -- but the nginx package test did not. So now let's try something a little bit different: I'll go ahead and run it on a remote server. First, let's log into the server with SSH. And we'll run the same two tests here to make sure that nginx is or isn't installed, and that we have a tmp directory. So this folder does also have a tmp directory, but it's got nginx installed as well. Let's exit out of here for now and go back to the previous screen, and we'll run our InSpec profile on it remotely.
So, a couple things to point out. I'm using the -t flag to run it under the Ubuntu username at the IP address of my server from the last section. And I'm using the .pem file that's in my directory here. We also see that the target is listed as the same thing on port 22, which is the port for SSH.
All right, that's it for now. Thanks for watching.