An Automation to Evaluate Terraform Code PR using OPA and Jenkins

Hello, Readers! This article is a continuation of my previous articles on using OPA for Terraform. So if this feels like gibberish, I suggest going through it first 🙂

Ideally, Sentinel would be perfect for; well Terraform. It’s literally tailor-made for it 🤪 However, I always look for free or open-source solutions, as it gives me greater level of customization. So I tried to create my own automation for automatically running OPA for a Terraform code and decide whether to run or abort the terraform apply command.

And much like the majority of automated solutions, we have Jenkins as the core. Seriously, can you imagine the world without Jenkins?

Jenkins ♥ OPA

Now let’s see it all about our goals. Let’s list them down

• Terraform code should be evaluated before creating/updating/deleting the resources
• Check the code quality using the OPA policies we’ve written
• Run or Abort depending on the code quality report
• Ability to run with no (or minimal) human interactions. Simply trigger from a Git PR
• Feedback for the developer created the PR. Preferably via an Email or Slack
• Good to Have: As rules apply to environments differently, adjust the gravity of the quality rules depending on the environment

Great! Now let’s decide what our architecture should look like.

Our Architecture!

Now Let’s looks into the implementation steps

1. First phase is simple.
- Create a Jenkins job for OPA validations
- Setup a web-hook to trigger the Jenkins job for every PR
- Configure an Email Gateway or Slack for the feedback.

Jenkinsfile for the Jenkins Job

As you can see, I’ve divided my tests into four groups.

• Detect infrastructure drifts. Terraform does not provide infrastructure drift detection unless you are using Terraform Cloud or Enterprise. So, we’ll be looking for that first
• Code validations such as Terraform syntax and usage of authorized Modules
• Compliance validations such as naming and tagging
• Security validations such as security groups and NACL rules

Now you can simply run this job and OPA will list all your violations. However, this is in the text format. You can install the Blue Ocean plugin, for an improved output with better visualizations

Now let’s try with few violations!

1. Raise a PR with a infrastructure drift

Output for an Infrastructure Drift

2. Raise a PR with a publicly open SSH port

Output for a Security Violation

You can create stages for every OPA policy too, and the output will show you exactly which rule you’ve violated.

Now to our bonus goal! The same violation can have different impacts in Cloud.

For example, assume we have two S3 buckets; The Dev bucket will contain some test data and the Prod bucket will contain sensitive data. If both buckets are created without blocking all public access, would it have the same severity? Of course not. We can tolerate a not-fully-secured Dev bucket which will contain some random data. So we should not abort building a Dev bucket and can consider issuing a warning to the user. However, a Prod bucket should not be allowed to create with the same settings.

This can be done through the OPA’s blast radius. We assign a violation a score depending on outside factors like the environment. For production, we will set the blast radius as 0. That means even a single violation will stop the build. However, for lower environments, we can set the blast radius to something above 0. This means we can tolerate a few violations. This scoring system should be customized for your organization depending on how serious you take the violations
You can find some examples with blast radius in the OPA sample Terraform codes