Inspec announced a while back that you can now run tests against Azure infrastructure and I’ve finally got around to trying it out. I have used Inspec in the past, but always in conjunction with Chef cookbooks.  In this article, I will walk you through how to I got started with Inspec-azure (no Chef in here!).


Preliminary Setup

Unless you have an existing Azure service principal account you want to use, you’ll need to create one to run your Inspec tests first.

I followed the instructions on the github page to set up my service principal: here

If you are creating a new service principal account, the homepage URL doesn’t matter…you can put whatever since we aren’t using the service principal for authenticating into another system.

The same with generating the client secret (password), type whatever you’d like but from that, Azure will give you a newly generated client secret, ensure you copy it and save it somewhere, you won’t see it ever again!  Here is what mine looks like once created:


Then you must add the service principal account as a contributor on the subscription. This is nicely documented in the Inspec-Azure github page linked above.

Before we start to write any tests, we also need to perform local configuration. There are two different ways I tested, I was successful with each, both described under Azure Platform Support: here

If you’ve previously done any sort of service principal authentication with Chef or other platforms, you probably already have the credentials file located in your users folder, .azure. Just add the subscription and service principal account identifiers.

I did have issues when I put double quotes around my client id, client secret and tenant id as shown in the Inspec doc example. Once I removed the quotes, it worked fine.

If you are creating .azure folder and credentials file for the first time:

  • Create the .azure folder from the command line: cd ~; mkdir .azure

Do not save a file extension on the credentials file.

If you edit it in notepad++, ensure you scroll up to the top and choose “all types” as shown below:

Deploy Azure Resources

You will need Azure resources to run the Inspec tests for the next section. If you have a repo where you deploy ARM templates, you can use that or if you are completely starting from scratch, you can go into the Azure portal and just deploy a VM.

To deploy a VM from the azure portal, select Create a resource from the upper left. I try to use cheap machines for windows examples, so I search for [smalldisk] Windows. Any of these options will work.

Disclaimer: I have only tested against Windows machines :)

Now I’ve got my “house keeping” done, time for the real fun. I am assuming at this point you have Inspec downloaded locally, if not, you can grab it here. While writing this tutorial I am running on Inspec 2.2.112 but the most recent package is 3.0.9.

The PSL of Inspec

This example is going to be very basic…it is fall time, it is the basic b*tch of Inspec tests for Azure, I hope you like Pumpkin Spice Lattes!

I went to a directory where I have code to deploy my azure resources and at the root of the directory, just run the command to create your Inspec profile:
inspec init profile azure-demo-profile in my case.

This will create a folder structure for you. In the Inspec.yml, ensure you have a depends on Inspec-azure. This is a resource pack we are importing.

You can create custom resource packs which have resources and run tests, for the inspec-azure resource pack, we are only importing the azure resources. This allows us to reference these resources in our tests. This import may not be necessary if you are running a more recent version of Inspec.

Well, that was interesting and all, but how can I actually use it…?

One example from the demo in this post that relates back to my current organization, they are trying to ensure everyone uses managed disks in Azure. Well, here as a dev I can locally run this Inspec test that will fail if I don’t have a managed disk, I could also run Inspec tests during CI/CD.

Application Of Inspec-Azure At A Larger Scale

How could this help me and my organization?

Do you have a security or compliance cloud team in your organization? At many places I’ve worked Security is always behind the ball. You’ve already deployed your resources and ready to go to production or already in production when the security red flashing lights start to go off.

These teams could start to shift left if they put these tests into code, specifically Inspec tests to for all of that ‘no-no’ behavior. This would effectively allow for security tests to run in each team’s or products CI/CD process.

I am not saying this is an easy thing to implement, it will still take time and practice for it to become second nature.

A Security team may want to create a custom resource pack which teams then import on the local Inspec.yml file (i.e. becoming a consumer of the security tests, allowing teams to pull the latest test), an attributes file would also need to be generated to pass in things like resource group and the name of the resource itself (the VM name in the case of our demo).

If you are even more sophisticated, instead of having inspec.yml files in each repo, you can build a library or module to grab and run them in your CI/CD.

Keep in mind, Inspec is a free tool. If your company does have Chef licenses, and is using Chef Automate, there are very cool Chef Compliance tools built in and you can create all sorts of pretty dashboards with the results.

Chef Automate is a tool you must purchase while just running the Inspec tests in our example was free.