IaC scanning tools are crucial to engineering your platform’s code securely and following your organization’s compliance and best practices by creating and enforcing the rules, through code allowing you to automate and integrate these into your software development lifecycle (SLDC).
A good engineering team accepts human error to be, well human and introduces checks to eliminate, mitigate or monitor human error in an automated and systematic way, the tools we will present below are exactly part of the solution.
In this guide, we’ll look at some of the available IaC scanning tools, and discuss how they work and how you might use them.
Choosing an optimal scanning tool is important. Some scanning tools are made specifically for an IaC tool whilst some are compatible with multiple IaC tools. We’ll be exploring four of these tools and their best use cases.
1. Open Policy Agent
Open Policy Agent (OPA) is an open-source policy engine that provides a portable framework for IaC environments. With OPA, you can scan your IaC code and enforce compliance with your specified set of rules or standards. Policies are written declaratively using OPA’s native query language called Rego.
As a multi-purpose toolset, OPA provides support for a wide range of tools used to build your platforms from Cloudformation Hooks, Terraform, Helm or Dockerfile, but you can extend the implementation even to your k8s cluster itself, see documentation here.
OPA can be integrated with your IaC code as a daemon or as a library. To run OPA, you’ve got various choices available. You can :
Let’s see an example of how we can use OPA to check IaC code for security issues and best practices compliance.
OPA with Terraform and Kubernetes
OPA can be used to scan Terraform no matter the Public Cloud provider it’s orchestrated with.
It provides conftest — a testing utility you can use to scan Terraform code changes.
To install conftest follow the instructions available here.
conftest will ensure these changes meet compliance checks by looking for deny, violation, and warn rules.
For example, we can use conftest to scan Terraform code configured to create new S3 buckets that meet your bucket encryption policy by checking both if it is enabled, the type of CMK used and if you are enforcing these configurations at the bucket policy level as well.
Note: Terrascan which is written using OPA’s Rego language allows you to scan Terraform, CloudFormation, and Kubernetes files detecting errors and security issues before provisioning your AWS resources.
OPA can also be used to safeguard Kubernetes control policies by scanning for vulnerabilities in code requests before they’re deployed,
conftest can be used to inspect K8s configuration YAML files by running:
$ conftest test deployment.yaml
OPA Admission control
In Kubernetes, Admission Controllers enforce semantic validation of objects during create, update, and delete operations, With the OPA agent you can enforce custom policies on Kubernetes objects without recompiling or reconfiguring the Kubernetes API server, why this is useful? It closes the loop between development pipelines and deployment, for example, if someone with K8S access tries to manually deploy an app your policies still get enforced.
Compared to other IaC scanning tools, OPA provides the widest coverage on a single tool.
Other options focus on one or two specific IaC tools but OPA is the broadest. OPA also has Rego, a query language that distinguishes it from other of the tools we looked into.
KubeLinter is an open-source static analysis tool that scans Kubernetes YAML manifest files and Helm charts templates.
Helm charts can be scanned with the default values or by specifying the values override files.
It confirms if the code configuration meets best practices and is free from security issues. Specified rules determine which errors and misconfigurations to flag or ignore; it comes by default with a “DB” which can be expanded and configured to your organization’s security and compliance requirements.
Using KubeLinter involves three basic steps.
kube-linter lint manifest.yamlkubelinter lint ./my-helm-chart/
For helm charts, if you are using an override values YAML file simply make the fixes there and re-scan again.
kubelinter lint ./my-helm-chart/ -f override_values.yaml
Upon scan completion, KubeLinter generates a list of checks it made, errors it discovered and recommended fixes with documentation links.
You can also get the list by running:
kube-linter checks list
Once the code fixes are done re-run the lint and validate your changes.
Compared to other IaC code scanning tools, KubeLinter is pretty easy to set up. But, it has limited functionalities when compared to OPA. For example, its only use is checking Kubernetes manifest files. It’s also only available in Go.
It is customizable and expandable, you can write additional policies thus extending or adapting to your organisation’s policies and requirements.
cfn-nag is an open-source linting tool that scans AWS CloudFormation templates ensuring they meet security best practices. It does this by looking for patterns and comparing them against specified rules. These rules apply when whitelisted and don’t apply when blacklisted. You can run cfn_nag_rules to see a list of these rules.
Installation instructions can be found here.
To use cfn_nag to scan a CloudFormation template:
$ cfn_nag_scan --input-path test_cfn_template.json/yaml
You can scan a directory and this will scan all .json, .template, .yml and .yaml files.
Upon completion, you can:
Cfn_nag is similar to Kube-Linter in some ways. First, they’re both static analysis tools that apply a specified set of rules or avoid them.
Secondly, they both focus on a particular IaC tool and are available in one programming language. cfn_nag: Ruby and KubeLinter: Go.
On the other hand, cfn_nag is very different from OPA. While OPA has a large number of use-cases, cfn_nag’s entire focus is on enforcing security compliance.
4. AWS CloudFormation Guard
Also called cfn-guard, AWS CloudFormation Guard is an open-source tool that finds non-compliant code. As a multi-purpose, policy-as-code tool, it works well with many IaC code tools with JSON and YAML-generated file configurations. Examples are CloudFormation, Terraform, and Kubernetes manifests amongst others.
To achieve this, cfn-guard provides a domain-specific language (DSL) that allows you to define, test, and enforce policy rules.
Binaries are available here for download.
To scan a CloudFormation template using the Guard CLI:
cfn-guard validate -d your-cloudformation.template -r your-test.rules
This will you give a sample result such as below:
Summary Report Overall File Status = PASS
You can also integrate cfn-guard in your CI/CD pipeline using AWS CodePipelines.
For the terraform users, you can also check your terraform output files, you will have to convert the traditional .bin format to json format to do so.
AWS CloudFormation Guard is preventative governance and compliance tool (shift left) ideally to test your code before deployment on your pipeline or before you apply your code.
Also, cfn-guard and cfn_nag are quite similar as they both require pre-defined rules to scan CloudFormation templates.
Checkov is an open-source static analysis tool that helps you scan your cloud architecture for misconfigurations.
checkov utilizes a policy-as-code framework while providing a command-line interface that helps you manage your scan result and provides multi-platform support, you can use it to scan configurations of popular IaC like Terraform, and AWS SDK, CloudFormation, Kubernetes manifests helm charts and your docker files.
Because of this, you can use a single tool for many of your pipeline steps and artefacts facilitating the nr of tools to learn and maintain by our teams and pipelines.
To scan an IaC file using Checkov.
checkov -d ./directorycheckov --file /user/tf/example.tf
You can add exceptions or set specific configurations for your scanner in the .checkov.yaml file and these can be global or specific to the code by placing them in the folder you are going to scan.
Checkov is similar to OPA in that they both use policy engines. Like OPA and cfn-guard, it also supports multiple IaC platforms.
However, it’s identical to cfn_nag and Kube-Linter because they’re all static analysis tools and are available only in one programming language.
We have mostly talked about security policies on the “left”, ie to scan your code while you are developing or at the pre-deployment phase of your pipeline, now I want to quickly talk about a tool on the “right” (operating) specifically for Kubernetes.
Kyverno is a policy engine designed for Kubernetes. It can validate, mutate, and generate configurations using admission controls and background scans. Kyverno policies are Kubernetes resources implemented through Custom Resource Definitions (CRDs).
See installation instructions for the helm chart here.
Kyverno is installed as a k8s operator and will integrate with k8s admission control and by default will only audit but can also be set to block.
As we mentioned above, it uses the same k8s yaml manifests using its own CRD’s implementation making it k8s native, and also it will only apply to k8s resources.
For policy examples, you can go here.
This tool sits on the “right” aka. the k8s cluster where your application is being deployed, it is not a single solution, you must pick other tools from above to implement on the development lifecycle of your platform and software teams.
The big advantage is that it protects your cluster from any deployment outside your pipeline scans and controls before it becomes a problem.
OPA also offers a very similar feature, but your teams might find the yaml preferable to the rego language which isn’t very intuitive and has a longer learning curve.
As more organizations realize the immense benefits of setting up automated IT infrastructure management, efforts have to be made to ensure IaC tools are augmented with adequate security and compliance checks.
It is important to have automation that scans and maintains the standard of quality and compliance as new members contractors etc work in your organization, this allows more centralized security and compliance across the board.
But it is important to understand that deployments can happen either by necessity or maliciously outside your pipelines and thus breaking your security and compliance, setting proper policies to monitor on the “right” should also be on your scope.