Everything is Code. Why and how you should test your Terraform

Originally posted on SogetiLabs: https://labs.sogeti.com/everything-is-code-why-and-how-you-should-test-your-terraform/

’ve written in a previous blog that for writing maintainable code, you really should automate your tests. Currently we see Terraform really taking off as the standard to provision and deploy almost everything in cloud like Azure and AWS. In this short blogpost I will show how you can start testing your Terraform code using the Open Policy Agent.


With Terraform, engineers write declarative statements that, when applied, result in for example a network, of a database:

Write Declarative Configuration Files

This obviously is great because you can automate and repeat your steps minimizing the manual labour of setting up services. Next to that, you can reuse components so all provisioned services will adhere to the same standard.

What about standards and compliancy?

In the previous example, a network will be created with some IP range, in a specific location from Google.

If you use any cloud, you should have some policies in place. It is not a free-for-all, do whatever you want, scenario. It could be very important where your data resides. In that case you don’t want to enable teams to deploy in non-compliant regions.

With code however, especially in the sample shown above, it is not directly clear what is allowed. Some examples of questions DevOps team may have are:

  • Am I allowed to create a public IP address on a machine or database?
  • Am I allowed to deploy services in the US or only in Europe?

Worst case, the team finds out when they deploy their services onto their cloud environment. In case of Azure, policies can block a certain location, blocking the entire deployment of their stack.

This means they have to go back to trace why something is wrong, adjust the code, go through all steps again and hope they did not miss anything.

Shift left

One solution to this problem is to test as early as possible. If a team gets feedback on their code, this will save a lot of time in the stages later on. It will also give the teams the confidence they are doing things right!

Open Policy Agent (OPA)

OPA states the following on their website:

Stop using a different policy language, policy model, and policy API for every product and service you use. Use OPA for a unified toolset and framework for policy across the cloud native stack.

Whether for one service or for all your services, use OPA to decouple policy from the service’s code so you can release, analyze, and review policies (which security and compliance teams love) without sacrificing availability or performance.

Source: Open Policy Agent website

Using OPA for testing your Terraform plans

You can use Open Policy Agent for a variety of use cases. Testing Terraform plans is only one of them, but really interesting for DevOps team.

The language for writing the OPA policy is called rego. It is easy to understand and should be relatively simple to learn. To get a grasp, take a look at the explanation of the language on the OPA site: https://www.openpolicyagent.org/docs/latest/policy-language/.

A very complete manual is located at https://www.openpolicyagent.org/docs/latest/terraform/ and helps you understand writing a test.

The great thing about the tool, is that you can use it in your pipelines, running the eval command in for example Azure DevOps. There is even an installertask for Azure Pipelines.

Getting started

If you are using Terraform, just download OPA, and go to the getting started page. Use the given example to test against your own Terraform plan outputs.

Just want to play around with the rego language? The site https://play.openpolicyagent.org/ contains several examples, and makes exploring easy, as it is an online playground without the need for installing anything!