Testing your infrastructure with Inspec
Infrastructure as code(IAC) is not a luxury anymore but a necessity for Devops teams to be efficient and effective. Most of the teams I coach either already have implemented or in the process of implementing their infrastructure as code. At some point during coaching assignment, all these teams have asked exactly same question – “We already use tools (Terraform, CloudFormation, Ansible, Packet etc) to create infrastructure. Why should we test it again? Obviously, we don’t doubt these tools nor we want to test these tools, right”.
Why test infrastructure
Because it changes. Because it is code. In the world of IT, anything that changes need to be validated if it still matches the desired result. Basic principles of software development should be applied while creating infrastructure by code. Here are my top 5 reasons why you should test your infrastructure code.
- Continuous compliance and security standards: Infrastructure testing tools(such as Inspec) will help you to detect violations and report so you can address appropriately.
- Shift left approach: Move compliance checks, security validations, feedback loops on IAC changes more towards left of delivery pipeline.
- Faster troubleshooting: If your application is not working as expected, it becomes easier to narrow down if it is due to environmental/infrastructure related.
- Make changes with more confidence: Automated verifications of IAC provides safety nets that enable teams to make changes with confidence.
- Focus on fire prevention rather than firefighting: By detecting problems/symptoms sooner enable teams to take required corrective measure before it escalates and disrupts business.
What and Why of Inspec
Inspec is an open source framework written in Ruby which helps you to test your infrastructure. Inspec validates actual state with desired state. I hear you say “Hey! Even terraform plan can give me this information”. Yes, terraform (or other similar tools) will tell you if your infrastructure definition matches actual state. However, let’s look at a practical use case.
You want to ensure all your web servers are associated with certain sub-nets and those sub-nets belong to certain security group. You might also want to verify ingress and egress rules. Another use case: How do you ensure someone else (because of shared tenant or otherwise) have not added an extra security group or sub-net? There are numerous use cases you can derive based on network configuration, file system, system configuration etc. Well, this is where inspec will come to your rescue.
A quick anatomy of above tests:
- Describe: keyword of Inspec which you can roughly equate to “test” fixture
- aws_security_group/aws_ec2_instance: Out of the box resources of inspec
- parameter to resource: A way to identify the resource. This can be parameterized by attributes file or from a terraform state file.
- Its (‘…’): a property of the resource which needs to be compared
- should include(…): a condition which gives the test result.
Why I prefer Inspec? Here are my top 5 reasons
- Flexible: Inspec is incredibly flexible. It offers numerus resources out of the box. However, it is also quite easy to create your own custom resources to meet your requirements.
- Easy to write and read: Inspec tests are very easy to write and read and they closely resemble human readable format.
- Remote testing support: You don’t have to install any packages/tools on your target infrastructure. Inspec use ssh/winrm to carryout testing.
- Platform agnostic: Inspec can be used on multiple platforms like windows, linux (different flavors), docker and multiple cloud providers aws, azure
- Open source: Inspec is an open source and supported by Chef.
How to get started
Introducing a new tool or a practice to your teams can be done in multiple ways. Here is what worked for me. Again, here are my top 5 steps to introduce Inspec
- Make Problem visible:
This is obvious but obvious pain is not always obvious 😊. This is especially true with IAC as rate of changes encourages teams to bear the pain.
- Familiarize with the tool:
I usually arrange a working lunch or couple hours of hands on session with teams and guide them through some simple tests. This really helps teams to get a good understanding of Inspec and encourages them to tryout in their projects.
- Identify critical yet simple use cases:
Start small. Pick one or two simple test cases, possibly identify the part of infra which changes often. The key is to have a small enough test case yet which gives value to the team.
- Start with non-production environments:
Test environments change more often (manually or otherwise) than production. I suggest teams to target their tests on test environments for initial 1 or 2 sprints. This gives them enough feedback and put this on their radar. Once they are comfortable, this will become part of their DoD.
- Make these tests part of your pipeline:
Make sure these tests are part of your pipeline. Remember, Inspec tests can be used for compliance and security auditing. By having these tests in a pipeline will also helps in meeting required complacency standards.
Refer to https://www.inspec.io/ for more information. You can find lot of hands on tutorials here https://learn.chef.io/modules#/