Terraform security tools — spend minutes, save millions

Creating Terraform code is not a simple matter. Sometimes the developers working on it might not have all the necessary security know-how. Other times, there is not enough budget for perfecting and refactoring such seemingly trivial issues. Perhaps there isn’t sufficient time to perform penetration tests before the Christmas sale? After all, the application is working and from a short-time perspective, it's tempting to leave those passwords hardcoded and focus on the next shiny, cool functionality that will bring tons of customers. Eventually, there will come a time for those backlog tasks buried by time and dust, won’t there?

Security awareness

Security awareness is still underestimated in many companies. It may not be a surprise that some start-ups or small companies don’t have the time or budget for it. They might not have created a proper DevOps culture in their work environment. However, this same issue also affects the top corporations that have well established, mature projects. Below are just a few examples of large data breaches from recent years:

• Facebook, 2019, 533 million users
• Marriott International, 2018, 500 million customers
• Linkedin, 2021, 700 million users
• Alibaba, 2019, 1.1 billion rows
• Cam4, 2021, 10.8 billion records
• TMobile, 2021, 45 million records
• Apple, 2021, 12 million records

And there are many, many, many more. Long gone are the days when a big breach was a hot topic on social media. It’s almost like it’s become the new norm.

Most common security mistakes

The most interesting part is that most of the above-mentioned breaches are not super complex, matrix-style hacker attacks. They are just small human errors that are easy to prevent. They are caused by a whole list of factors:

• Too wide and unnecessary data access for employees that don’t need it
• Open access to a crucial S3 bucket
• Unnecessary open ports
• Ignored security patches.
  

Source: TESSIAN

According to RedHat’s survey “94% of respondents experienced at least one security incident in their Kubernetes environments in the last 12 months”

In the past 12 months, what security incidents or issues related to containers and/or Kubernetes have you experienced?

Source: RedHat

We should not be very surprised if someone breaks into our house when we leave the door wide open. It’s also worth noting that employees are often rushed and stressed. Therefore they make simple mistakes. Sometimes they also have too many houses and too many doors to close and lock. A simple solution would be to automate the process and implement a tool that would remind us when we forgot to close one of them.

Enter Terraform static code analyzers

As luck would have it, there is a growing amount of tools that can make addressing the security issue painless, fun and less time consuming than ever before. Let’s go through some of the most popular static code analyzers for Terraform.

First, let’s use the same examples of Terraform code to stay on the same page during the comparison. There is an open-source GitHub repository that presents a comparison of the default policies of those tools. It is definitely worth checking it and at the same time, we can use that code as examples of unsecured IaC. After cloning the repo please go into the path test-cases/terraform/aws/best-practices/cloudfront_not_using_waf or follow labs with your own IaC.

Tfsec - A static analysis security scanner for your Terraform code

Tfsec is very easy to get started with. Installation and running the tool on a local machine should take less than a minute. It provides built-in integration for Github actions. It also allows you to turn off some irrelevant checks or create custom ones for your system using simple JSON or YAML format. Tfsec is one of the few scanners that have started to put a focus on smaller providers like Digital Ocean. It is very handy when combined with the extension for Visual Code. However, they have the least amount of default policies and few built-in integrations for common CI/CD tools. I would love to see the project develop more but they have to catch up a little to compete with the most mature tools.

You can try Tfsec on your local machine by running in the directory of the project:

brew install tfsec
tfsec .

The checking itself is lightning fast. The output has very useful links to documentation on various sites. What I like about it are the very friendly interface and docs. The design of the tool, logs and overhaul is very pleasing to the eye.

Tfsec result example

If you find a particular check irrelevant, you can easily turn it off or override severity. I guess that we can all agree that CloudFront allowing unencrypted communication is not that CRITICAL. Let’s change it to LOW severity and let’s remove policy number AWS002 which reminds us to enable logging for the S3 bucket. We have to create a JSON or YAML file that will serve us as a list of our own rules and policies. It can be created as a global list for all projects or locally for each of them. For now, let’s make it locally just for the current file.

vim tfsec.yaml 

In the file override definition using the id of the policy and define the policies to exclude from the scan:

severity_overrides:
AWS020: ERROR
aws-cloudfront-enforce-https: LOW
exclude:
- AWS002
- aws-s3-enable-bucket-logging

Now run the Tfsec with a flag pointing to the config file:

tfsec --config-file tfsec.yml

Results as expected:

We can define our own policy. Let’s ensure that every AWS resource has a tag with the name of the belonging Project. The custom policies have to be in the .tfsec directory and have the suffix _tfchecks.json or _tfchecks.yaml

mkdir .tfsec
vim .tfsec/my_name_tfchecks.yaml

---
checks:
- code: CUS420
description: AllS3bucketsshouldhaveprojecttag
impact: Terrible!
requiredTypes:
	-resource
requiredLabels:
	-aws_*
severity: WARNING
matchSpec:
	name: tags
	action: contains
	value: Project
errorMessage: Don'tforgetaboutprojectag
relatedLinks:
	- http://internal.acmecorp.com/standards/aws/tagging.html

Tfsec custom check example

That wasn’t so difficult. Now let’s run the scan and see if our project fails the new check.

tfsec .

Hungry for more? You can check additional examples in their official docs.

Terrascan as a top Kubernetes Security Tool

Terrascan is considered one of the top 5 popular Kubernetes Security Tools by RetHat. GitHub Terrascan can be integrated into various platforms and configured to validate policies to provide run time security. Currently, Terrascan supports the following integrations:

• Kubernetes (K8s) Admissions webhooks
• ArgoCD
• Atlantis
• Github and GitLab or CI/CD pipelines

It has a noteworthy number of policies for AWS, GCP, Azure, Kubernetes and Docker. Unfortunately, the tool was significantly the slowest one. You can ignore or change the severity of the policy only by removing it from downloaded policies. Results of the scan lack clarity, sometimes the same errors appear twice for the same occurrence in the code.

Let’s take a look at Terrascan and install it locally:

git clone git@github.com:accurics/terrascan.git
cd terrascan
make build
./bin/terrascan

Download the latest policies with:

terrascan init

And try against your Iac:

terrascan scan

Terrascan result example

You can use OPA to create custom policies using the Rego language. Nevertheless, I found it quite a complex and slow process especially compared with Tfsec and Checkov where the formats of new policies are being created respectively with JSON or Python which are well known in the society.

package accurics

privateRepoEnabled[api.id] {
api := input.github_repository[_]
not api.config.private == true
not api.config.visibility == "private"
}

Terrascan custom policy example

Checkov — another top Kubernetes tool

Checkov also can be found on the list of the top open-source Kubernetes Security Tools by RedHat. It can scan IaC across platforms such as Terraform, CloudFormation, Kubernetes, Helm, ARM Templates and Docker. Custom policies can be introduced in YAML or Python. It scans for compliance with industry standards like HIPAA, SOC2, PCI-DSS etc. Checkov allows for easy integration with

• Jenkins
• Bitbucket Cloud Pipelines
• GitHub Actions
• GitLab CLI
• Kubernetes
• Pre-Commit
• Docker
• Terraform Plans and Third-Party Modules

The output of the scan has high readability and has a link to a guide that explains the issue. However, I found that often those explanations were not very helpful and sometimes just confusing. Checkov also introduces the ability to scan only the output of the Terraform plan. It seems that the tool receives a lot of attention from the creators and the incoming new versions will bring a lot of new features and integrations. It’s also possible to use Checkov with the BridgeCrew cloud platform that gives the possibility to streamline cloud security and enforce policies throughout the entire development lifecycle.

Shall we dive in?

pip3 install checkov
checkov -d .

Checkov result example

One of the coolest features is the Checkov extension for Visual Studio which helps you write secure IaC while you are creating it and I simply love it. However, you need to create a free account in BridgeCrew and platform and use your token in order to be able to use it:

Checkov extension for Visual Studio in action

Let’s repeat the steps from previous tools and try to ignore or override default policies. We can skip checking for the particular resource by adding a comment for checkov:

And now let’s try to create a custom policy. It’s possible to do it with Python or YAML format. I’ve chosen the previous one. You can put your new policy in the same location as the default policies or create a dedicated location for your custom ones. In this case we’ll go with the default directory:

vim ~/.local/lib/python3.9/site-packages/checkov/terraform/checks/resource/aws/CustomCheck.py

from lark import Token

from checkov.common.models.enums import CheckResult, CheckCategories
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck

classS3CustomCheck(BaseResourceCheck):
def__init__(self):
	name = "Ensure that each S3 bucket has Project tag"
	id = "CUS_1337"
	supported_resources = ['aws_s3_bucket']
	categories = [CheckCategories.BACKUP_AND_RECOVERY]
	super().__init__(name=name, id=id, categories=categories, supported_resources=supported_resources)

defscan_resource_conf(self, conf):
	"""
	Looks for ACL configuration at aws_s3_bucket and Tag values:
	https://www.terraform.io/docs/providers/aws/r/s3_bucket.html
	:param conf: aws_s3_bucket configuration
	:return: <CheckResult>
	"""
	if'tags'in conf.keys():
	environment_tag = Token("IDENTIFIER", "Project")
	if environment_tag in conf['tags'][0].keys():
	return CheckResult.PASSED
	return CheckResult.FAILED

check = S3CustomCheck()
Checkov custom check example

Checkov custom check example
Now run Checkov as before to see the results of your new check:

checkov -d .

Checkov stands out with the biggest amount of integration with external tools. Let’s see how it works and let’s try to create a GitHub action that will fail the build if our policies are not met. In your GitHub repository choose Actions -> New workflow and copy-paste this action:

---
name: Checkov
on:
push:
branches:
-master
jobs:
build:

runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: SetupPython3.8
uses: actions/setup-python@v1
with:
python-version: 3.8
- name: TestwithCheckov
id: checkov
uses: bridgecrewio/checkov-action@master
with:
directory: .
framework: terraform

Now with each push, the action will check our IaC and run tests with our policies. Integration with other tools is as straightforward as this one.

So which Kubernetes Security Tool is right for you?

Checkov is certainly the most mature of the Kubernetes Security tools, Terrascan is the most popular, and Tfsec is definitely the most user-friendly. My personal choice would be Checkov, purely because of its maturity, level of development, and integration. It has already become part of my toolstack.

However, I’m not going to resign from Tfsec and Terrascan and neither should you. Installing each of the tools or adding them as one of the steps of your CI/CD is a no-brainer and won’t take much time. At the same time, it’s important to note that the policies from the different tools don’t completely overlap, which means that using all of them would bring you the highest coverage for security mistakes. Another question is which should you use for creating your own policies and that’s what each of us has to answer for ourselves. Each tool uses a different logic and language for custom policies. Simply choose the one which you are the most familiar with or even better, the one which you want to learn. The only reason for not including one of the tools in your system is that they may not have integration with your preferred tools — that’s where Checkov won’t fail you.

It’s all about constant improvement

Security issues are certainly on the rise and it’s challenging to solve them all. Fortunately, we can arm ourselves with tools like Checkov, Tfsec and Terrascan and immediately gain access to the vast knowledge and experience of their creators. However, it's a predominant factor to know that those tools will NOT catch every possible security issues that might arise. Even though they will tremendously support your work, don't leave your guard down. Only by adopting a DevOps culture, through constant evolution and improvement, a company can hope to prevent any malicious attacks.