Inspec — the missing piece for compliance as code from infrastructure as code evolution?
A look at how Inspec is a key tool in order to evolve from infrastructure as code to compliance as code.
It’s day one at your new job and good news… they have an innovative new project for you to get your teeth into. It goes by the name of ‘Infrastructure as code’ and whilst it’s adopted a new identity it’s everything you have been doing in your professional career to date, in fact you might event claim you had been pioneering it from the beginning. You take a seat at your new desk, spin around in your chair and all of your team are raring to go.
The architecture arrives so you take a look, at a first glance it’s very basic and high level, let the madness commence! Developers left, right and centre are coding ‘infrastructure as code’ furiously, but no one really knows what the end goal is, what does finished really look like?
A few short months pass and all the Jira stories are completed and everything works in the demo. “Great stuff, lets push this into a new environment or release it to open source”.
But then, one curious person at the back of the room puts up their hand. “Shouldn’t we test this first? A code review maybe? Have we written any tests? Kitchen Terraform is pretty hard to write and often inaccurate.”.
How do you know that the output matches the initial design? After all, there was never a low level architecture or a blue print for how ‘infrastructure as code’ should look.
And herein lies the problem…..
How do we take back control without getting lost in iterations and Jira stories?
We need blue prints.
Infrastructure as code is dead, we’ve move on… Welcome compliance as code
I have written Chef cookbooks in the past and I am a big fan of Chef. I have tested a lot of cookbooks in a test kitchen and this used to work great, but these tools could not scan cloud API’s, until Chef reinvented their testing software. I was therefore delighted when I discovered a new piece of software… enter Inspec 2.0 (round of applause, as the architects and managers go wild!).
Inspec gives us the ability to write compliance as code baselines for just about anything: CIS compliance baselines for servers, infrastructure as code baselines for cloud platforms, configuration baselines for networking equipment and much more.
You need to check that resources exist in your chosen cloud provider post Terraform application. Below is an Inspec profile that baselines a VPC and two instances that have been deployed into that VPC.
After running Inspec you will be able to confirm from the CMD line that only one of the instances has been created, and that the instance that succeeded the original ‘my-super-cool-instance’ has been deployed to the wrong zone, it is the wrong machine type and it has an incorrect amount of disks attached.
Now engage the brain!
Inspec is very well documented, and just about any control that you can enforce within the cloud already has a related example within Inspec; for example check out the resources below. These two links have everything you need to get started.
Inspec is designed so that even high level word philanderers can code it, so these policies can be pre-prepared by the infrastructure architects prior to the developers even getting their hands on the almighty and powerful Terraform, and it is so simple!
“Hang on a second” I hear you cry. “I just want my developers to be able to check their Terraform apply outputs quicker, without having to do any console bashing and to run tests without so much ‘eyeballing’. How do I integrate my Terraform with Inspec?”
Remember those outputs in Terraform code gods? Here is a quick demo with AWS.
Let us put those into a json file and then use Inspec.
Just like magic
Now put that in pipelines, Jenkins, cloud build, code build, circle CI (or whatever makes you frothy) and spread the word that the definition of ‘end goal’ is being changed as we speak; order is on the horizon!
We are now able to test Terraform without all of the pain of Terratest and Kitchen Terraform.
How else could you use your new found super-powers?
Imagine automated drift remediation?… As now you have configuration baselines as code.
Imagine if you had clients with highly secure cloud platforms? You could write configuration baselines to match those client environments, so that when the time comes to migrate the code into its final location you stand a good chance of it actually working!
Imagine being able to take back the power… Are my developers working? Run your baseline and see how much comes back as green or red; has this changed since yesterday?
The possibilities are endless!
Compliance as code comes before any infrastructure is even written
“But how does this relate to AWS Config” I hear you ask…
AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources (in a ‘very similar’ way that Google does it). AWS Config is highly Terraform-able, plus Inspec has controls for some basic AWS Config functionality.
When it comes to post development cloud environments I would say — go ahead and use as many tools as possible, including those provided by the cloud providers themselves. In the ‘Wild West’ that is cloud computing, multiple levels of control are needed and any help is a bonus.
Inspec is still a relatively immature product and may not cover as many configuration controls as those made available by the cloud providers; compliance as code is not quite there yet, but it is certainly a brave new world. One day, all configurations will be in code; it’s the natural progression — expose the API’s, develop the tooling, and keep it dry!
Inspec may not solve all of the issues, but it is certainly one piece of the endless puzzle!