How do we secure Infrastructure as Code tools?

As its name indicates, Infrastructure as Code (IaC) is the practice of defining the infrastructure your applications run on as code and configuration files.  This allows us to not only automate the provisioning of the resources but also to subject it to the same lifecycle processes that historically have applied only to the application codebase.  If you're new to IaC, check out this article where we discuss infrastructure as code (IaC), what it is exactly, and the security implications of using IaC in the real world.

There is a multitude of infrastructure automation tools for implementing IaC; many come from public cloud providers such as Amazon Web Services’ CloudFormation and Azure’s Resource Manager (ARM), as well as projects that provide support across infrastructure platforms, like Hashicorp Terraform and Pulumi.

These declarative language-based IaC tools are a great fit for static analysis techniques, enabling enhanced abilities to detect and resolve security issues in them before the defined infrastructure is even deployed.  Patterns for security best practices in the IaC domain are continually being discovered.  As we continue to build the Snyk IaC product, we are striving to make it as easy as possible for organizations to adopt IaC by empowering developers to not only be aware of issues but also giving them context and advice around remediation.

Let’s take a look at some of the popular Infrastructure as Code tools and what security hardening measures you can apply at the code level to protect your applications and platforms.

Infrastructure as Code tools

Cloud provided Solutions

AWS CloudFormation, Azure Resource Manager (ARM),& Google Deployment Manager (GDM)All of the major cloud providers make their own IaC tools for automated infrastructure provisioning that declaratively define the desired state of your deployments using JSON or YAML templates and, in the case of the Google Deployment Manager, Jinja, and Python can also be leveraged.

Amazon Cloud Development Kit (CDK)Released in 2019, the Amazon Cloud Development Kit (CDK) allows developers to define their deployments in higher-level programming languages such as JavaScript, Python, or C# (see the full list of languages here).  Not only is this a more familiar syntax, but it allows for IDE integration and the ability to package up patterns into reusable libraries and tested code structures, rather than relying on copy and pasting JSON/YAML between projects.  The output of CDK actually is CloudFormation JSON, so what Amazon has done is provided a developer-focused environment that still leverages their battle-tested CloudFormation infrastructure orchestration tooling.

Cross-cloud Solutions

Hashicorp TerraformTerraform provides an automated provisioning tool that can be used to provision and configure across a wide variety of platforms and products via provider plugins. 

PulumiPulumi is an open-source, IaC project that provides SDKs in several programming languages for provisioning and managing resources across many platforms.

Issues to watch for and some scanning examples

Regardless of the cloud provider or IaC tool you chose to use, there are some common areas to focus on from a security point of view.   Let’s take a look at some of these along with some examples using Terraform and AWS.  All of these examples are in this GitHub repository and I’m including here some screenshots of how the Snyk IaC scanning tool presents potential issues found for each.

Credentials

In the top-level directory of our Git repo, there is a main.tf file where we see several common issues.   Snyk scanning reports one high and five medium-level issues as shown below.

First of all, you should never check in credentials of any kind to source control.  This seems like obvious advice but internet forums are full of examples of code repositories containing such things, many publicly readable!  Unfortunately, many of these examples were only discovered because they were exploited.  Often, this happens through an accidental commit by a careless user.  One of the more insidious ways this can occur is when a credential is committed and then removed in a subsequent commit; the developer may not notice it but that credential lives on in the repo history.  There are techniques that attempt to catch this issue, such as using .gitignore files or pre-commit hook scripts, for example,  AWS Labs “git-secrets”.

We also see a collection of findings that circle around IAM account passwords; it’s important to note that you get one policy per AWS account and if you set one up, you will override the default policy that Amazon provides so be sure to be explicit about all of these options.

Encryption on storage services

By default, EBS volumes have encryption enabled, but S3 buckets do not.  It’s important to check both to ensure compliance with your company policies and any regulatory entity guidelines.  In our demonstration repo, we have declared a couple of storage resources in the modules/storage/main.tf file which you can see being scanned below:

Here, we see examples of both violations being flagged, as well as a lower priority warning about not enabling S3 server access logging.   If we drill into one of these, there are details about the issue as well as it’s impact and a recommendation on how to resolve it.

The high/medium/low classification of each policy can optionally be changed to match your organizational policies.

Security Group / Firewall ingress and egress ranges

Moving to the modules/vpc/main.tf file we find another common issue of ingress access being set up in a wider manner than probably intended.

Similar to the hardcoded credentials issue, this often gets created during development or troubleshooting and accidentally committed to source control along with other work.  In this example, it’s highly unlikely that anyone really wants to open port 22 to the entire internet which is potentially what is happening here.  It’s critical to ensure that traffic into and out of your networks is locked down and only granted to the IP ranges that absolutely need it.

Key rotation

For our final example, we have the modules/pki/main.tf where a key is being set up without key rotation.

This is another case where the default behavior is often not the most correct from a security hardening point of view.   Of course, this recommendation assumes that your organization doesn’t have a separate process for rotating keys but if you’re using the cloud provider’s key management service, it’s a pretty good chance that letting it handle such tasks will be the best choice.

How secure are your IaC efforts?

Now that you’ve seen a few examples of issues that can very easily slip into IaC code, how sure are you that yours is safe?  Remember, security should not be an afterthought, you can run these same checks, plus checks for other cloud providers and Kubernetes against your repository right now, for free and catch issues before they get deployed or exploited.  

Create a free Snyk account and follow the instructions to create a project from your repository — within minutes you’ll have actionable advice for any issues that it finds.