How to Use Ansible and Chef InSpec Together
Learn how Chef InSpec can be used to audit any system with Ansible.
This short video demonstrates how to use Chef InSpec to analyze a raw Linux system, automate an Apache deployment using an Ansible playbook and verify that deployment using Chef.
This example shows how Chef InSpec can be used to audit any system – on-prem or in the cloud – regardless of whether it's configured manually, with Ansible, or with any other automation tool – without ever having to install a Chef Client.
For this demonstration, I'm using Chef Workstation. It provides the InSpec command-line tool along with all the other utilities necessary to work with Chef. It can be freely downloaded from the chef.io website. I've also installed Ansible.
I'm logging into a raw Ubuntu 20 node and running a couple of commands to show that the chef-client is not installed on the system.
On the coding side, I start with a Chef InSpec profile that audits five specific features of my Ubuntu node. I'll check that port 443 is listening… the small webpage I'm deploying has the correct content… that a specific version of Apache is installed… that ssl3 is disabled and TLS 1.2 is enabled. These basic entries test both system compliance and security.
Without installing anything on my target node, I now run the Chef InSpec command to execute my profile against it. I'm providing a local path to the file I just created and using ssh to target my Ubuntu node. A similar syntax can be used to test Windows systems.
Since I haven't yet configured my node, I expect most of these Chef InSpec tests to fail, and indeed they do. This is a modern Linux system without the vulnerable ssl3 enabled, so that test passed.
To deploy Apache on my node, I've created an Ansible Playbook. It will configure the webserver with local self-signed certificates and run on port 443. My entries include the apache-conf content I want… and actions to install Apache and some other necessary packages… create a secure directory for my certs… generate the certificates themselves… disable the default website running on port 80… enable my "Hello, world" website… and enable the SSL module.
When I've finished my Ansible playbook I can apply it with the ansible-playbook command. The output shows that Ansible is doing its thing and configuring my raw Ubuntu system.
When the playbook is done, I can re-run the same Chef InSpec profile I ran before. This time, the results are much different. All five of my tests passed, indicated by the green. The site is running the proper version of Apache… listening on port 443,.. returning the correct website content… and has TLS enabled.
To close the loop, I'll log back into the Ubuntu node and re-run the commands I used to check for the chef-client. As you can see, it's still not installed. Chef InSpec scanning doesn't require the Chef Client or any Chef configuration at all.
The final verification is the website itself. When I point my browser to the Ubuntu system – and click through the warnings caused by the self-signed certs – I can see my Hello, world website is indeed up and running.
This demonstration showed the command-line version of Chef InSpec, but you can also perform compliance and security scans using Chef Automate, the Chef management dashboard. Either way, you can use Chef InSpec profiles like my example… publicly available dev-sec baseline profiles… or hundreds of premium Chef CIS- and STIG-based profiles on hundreds or thousands of nodes, with no chef-client or Chef configuration necessary.