- Why Inspec?
- Keeping The End Goal in Mind – An Example of Successful Execution
- Getting Started
- Executing Inspec Tests
- References
Why Inspec?
From the Chef Inspec documentation overview:
“Chef InSpec is an open-source framework for testing and auditing your applications and infrastructure. Chef InSpec works by comparing the actual state of your system with the desired state that you express in easy-to-read and easy-to-write Chef InSpec code. Chef InSpec detects violations and displays findings in the form of a report, but puts you in control of remediation.”
Why I Like Chef Inspec
There are several reasons why I personally like using Inspec:
- It is Open Source and covered by the Apache 2.0 license.
- It is a CNCF Cloud Native Landscape Project.
- It is written in Ruby (I like Ruby).
- The interface is cli-based and works the same on Linux and Windows.
- It generates nicely colored and formatted, text-based feedback and reports.
- It can be used in CI/CD pipelines to automate code, configuration, and environment validation.
- The test definition syntax is easy to read and write.
- It is an excellent tool to support Compliance as Code.
Why Inspec on Azure Cloud Shell?
There are many ways to use Chef Inspec on various platforms and for a variety of purposes. I personally have used Inspec in the past for hybrid and private cloud code, configuration, and environment validation.
My work lately has been primarily with public cloud platforms, and so leveraging the power of Inspec as a cloud-native testing and validation tool was a natural choice for me. Leveraging Cloud Native (PaaS) capabilities first, before deploying third-party tools on custom-configured compute is always a wise idea when working in the cloud.
There are a variety of different ways to work with Chef Inspec – on Virtual Machines, in Docker Containers, on your local MacOS or Linux workstations, or even under an instance of Ubuntu Linux LTS on Microsoft Windows Sub-system for Linux (WSL). In this article, we will be focusing on using Chef Inspec specifically on Azure Cloud Shell.
Benefits of Using Azure Cloud Shell
Inspec is great. However, it does take time to set up Chef Inspec for the first time, and depending on the platform you are working with there could be quite a few steps involved in the setup. Unless you plan on automating your custom installation (which you should eventually consider), you will likely have to do it more than once for different projects and/or client engagements.
The benefit of using Chef Inspec on Azure Cloud Shell is that Cloud Shell has “deep integration with open-source tooling”. What this means for you is that Azure Cloud Shell is available with Chef Inspec, and with all the right matching dependency versions, out-of-the-box. Inspec comes ready for use with your Azure Cloud Shell instance, in either a Powershell or Bash command-line terminal.
The inspec core libraries and binary may already be installed once you log in to Azure Cloud Shell. If the command is not found, then try installing it as follows.
$ PS /home/jaime_lopez> gem install inspec inspec-bin
(now grab a coffee, since this may take a few minutes.)
Of course, as you mature your automation and CI pipelines, you will want to look at perhaps running Inspec as a container, function, or web-app of some kind and have it triggered as part of your pipeline – but that’s an article for another day.
Keeping The End Goal in Mind – An Example of Successful Execution
When inspec is properly configured, and your tests are well defined, then a successful test execution should look similar to the output in the following image:
What You Are Looking At
In the above image, inspec is being used to check:
- That a named resource exists (a vm named ‘jbl-lab-CanC-01’).
- That VNET has been deployed with the ‘10.9.0.0/16’ address space.
- That only one (1) subnet has been deployed with the name ‘default’.
This article attempts to guide you through how to configure such a test-suite for your own infrastructure testing and validation needs. Let us use the above successful execution output as an example of the goal we would be aiming to achieve as we progress through the following paragraphs.
Getting Started
In order to successfully execute inspec with an initial set of tests, the following steps need to be taken to setup and configure your inspec project workspace:
- Initialize Your Inspec Profile
- Setup Your Azure Environment Variables
- Configure Your Inspec Tests
Initializing An Inspec Profile
The first thing you want to do after you have confirmed that inspec has been installed correctly, is to create a new inspec profile. This is effectively the process of creating a workspace directory for your new inspec project.
First, create an inspec profile by executing the following command within your Azure Cloud Shell / Powershell terminal instance:
$ PS /home/jaime_lopez> inspec init profile --platform azure azure-inspec-tests
Since you are initializing a new project, you will be prompted to accept the product license. Type ‘yes’ to continue.
+---------------------------------------------+
Chef License Acceptance
Before you can continue, 1 product license
must be accepted. View the license at
https://www.chef.io/end-user-license-agreement/
License that need accepting:
* Chef InSpec
Do you accept the 1 product license (yes/no)?
> yes
Persisting 1 product license...
[PASS] 1 product license persisted.
+---------------------------------------------+
─────────────────────────── InSpec Code Generator ───────────────────────────
Creating new profile at /home/jaime_lopez/azure-inspec-tests
• Creating file inspec.yml
• Creating directory controls
• Creating file controls/example.rb
• Creating file README.md
PS /home/jaime_lopez>
Notice the directory structure that was created:
- /home/jaime_lopez/azure-inspec-tests
- inspec.yml
- /controls
- /controls/example.rb
- README.md
Also notice the ‘–platform’ command. This is used to specify the platform target for the inspec tests. This allows the correct profile configuration to be applied to the workspace for the work you will be doing with Azure.
This same ‘init’ command is expected to work on other platforms (again, if inspec is installed correctly).
Setting Required Azure Environment Variables
Now that you have initialized your inspec controls workspace directory, lets start configuring your inspec environment.
The following is how you would set up your Azure Environment Variables for Azure Cloud Shell.
Of course, if you are doing this on other platforms, your environment variables should be defined accordingly.
Within your Cloud Shell terminal, execute the following environment variables (pull this information from your Azure Portal):
- AZURE_SUBSCRIPTION
- AZURE_CLIENT_ID
- AZURE_TENANT_ID
- AZURE_CLIENT_SECRET
For example, set these variables in the following manner:
$ PS /home/jaime_lopez> $env:AZURE_SUBSCRIPTION="<your_azure_subscription_id>"
Configuring Inspec Tests
For this exercise, we are going to create two inspec controls called ‘azure_resource_group.rb’ and ‘azure_virtual_network.rb’. Both will reside in the azure-inpsec-tests/controls/ directory.
Within these controls, we attempt to define the following tests:
In ‘azure_resource_group.rb’:
- assertion that a named resource exists
(a virtual machine named ‘jbl-lab-CanC-01’).
In ‘azure_virtual_network.rb’:
- assertion that a VNET has been deployed with the ‘10.9.0.0/16’ address space.
- assertion that only one (1) subnet has been deployed with the name ‘default’.
The following are example inspec controls showing how to define the tests inspec will execute.
Notice the variables which we have defined, and which are subsequently used in the test definition with each of the ‘describe’ statements:
- resource_group
- virtual_network
- address_space
- subnet1
Let us take a look at the full content of the resource group control file:
$ PS /home/jaime_lopez> cat azure-inspec-tests/controls/azure_resource_group.rb
resource_group = 'jbl-lab-CanC-01'
control 'azurerm_resource_groups' do
describe azurerm_resource_groups.where(name: resource_group) do
it { should exist }
end
end
Now let us take a look at the virtual network control file:
$ PS /home/jaime_lopez> cat azure-inspec-tests/controls/azure_virtual_network.rb
resource_group = 'jbl-lab-CanC-01'
virtual_network = 'jbl-lab-CanC-01-vnet'
address_space = '10.9.0.0/16'
subnet1 = 'default'
describe azurerm_virtual_network(resource_group: resource_group, name: virtual_network) do
its('address_space') { should eq [address_space] }
its('subnets') { should eq [subnet1] }
end
As you can see, in both of these cases the control files are very simple and easy to extend to add further tests as may be required.
Executing Inspec Tests
Once your tests are defined, you are now ready to execute them to validate an actively deployed Azure resource group.
Below, we are going to have inspec execute the tests defined in our ‘azure-inspec-tests’ directory, and target a specific Azure tenant using the ‘-t’ command argument.
Execute the inspec exec command as shown in the following example:
$ PS /home/jaime_lopez> inspec exec azure-inspec-tests -t azure://<your_azure_tenant_id>
If inspec is installed and configured properly, and your inspec tests are defined correctly, then you should be able trigger a successful inspec test execution and generate results just like the ones shown in the image below.
I hope this brief dive into Chef Inspec on Azure Cloud Shell was informative, and I wish you well on your own your journey with DevOps, Automation, and Compliance as Code. Happy Inspecting!
The DevOps Joint 
Leave a Reply