However, the devil is in the details and trying to implement those tools in real life often comes with risks. In this article we explain those risks with using IaC, coming from a developer’s point of view.

Biggest Risks of IaC

Steep learning curve

To start with, using IaC tools without taking the dedicated time to learn some of their quirks and limitations can become not just an inconvenience, but a serious problem.

Many of the most prevalent IaC tools like – Terraform and CloudFormation – are incredibly simple to start. But they become very complicated as your requirements change over time. For example, trying to utilize custom resources in CloudFormation requires some insight into how CloudFormation works under the hood. Failure to delve into the inner details will put your organization at increased risk of configuration drift, pushing the wrong infrastructure components or obtaining a system in an incomplete state.

Another example that requires some deep insight of how Terraform works is with Terraform Imports. The official page mentions in the warning box that:

“If you import the same object multiple times, Terraform may exhibit unwanted behavior“

However, you will need to delve into the details in order to understand the nature of this unwanted behavior. What does it really mean? Does it create configuration drift? Does it break the local tfstate file? How can you prevent importing the same object multiple times? All of those questions need time and dedication to answer. As a developer, you should reserve that time as part of the process of learning the tool while using it for real projects.

Human mistakes

Some IaC tools have a distinct set of phases that you need to perform in a specific order. For example, in Terraform we have the following steps:

1. terraform plan : Creates an execution plan for what terraform will perform against the infrastructure.
2. terraform apply : Applies the plan.

Failure to perform a plan review before using apply can result in destructive changes. This is because a visual inspection beforehand gives you one more chance to review the changes before applying. The caveat here is that, by default, there is no requirement to follow the order. Directly applying the changes, skipping the first step, could lead to unfortunate mistakes.

The repercussions of missing a destructive change can be excruciatingly painful. It is recommended that you invest in establishing automated protections to apply changes to infrastructure. For example, instead of manually reviewing terraform plan outputs (which could be lengthy), you should invest in PR (pull request) automation tools like Atlantis to help in discovering any unintentional destructive changes early.

Configuration drifts

Terraform and other tools can help in maintaining infrastructure components and associated attributes, as long as they are managed solely by them. For example, Terraform cannot detect any drift of resources if you have applied while using other tools like Chef or Puppet. This could be a major problem for organizations still working on a variety of IaC tools that are unaware of each other or overlap their body of work.

Scanning for drift helps with figuring out those deviations between the IaC tool and the real infrastructure. Because each case is different, you will find there are virtually no public or private services that do that for you accurately. The best option for managing configuration drift for your organization is to make sure there is no overlap between the various IaC tools; any changes to the infrastructure are monitored by one IaC tool; and some sort of reporting and health checking are integrated. External checks can also sometimes help to verify that.

Difficulty protecting sensitive data and exposing ports

Although Terraform and CloudFormation can provision infrastructure components, there are some questions that need answering. For example, how would you know during the process if it leaked sensitive data? How would you know if the S3 bucket it manages in fact contains the security profiles you specified? Are you using a provider that leaks sensitive data to stdout? Did you unexpectedly open a port to the internet?  

These are only a subset of questions you need to answer when delegating your Infrastructure management to IaC tools. It’s easier to make a mistake and expose resources to the public web than the opposite, so there are a lot of things at stake here.

[In fact, in an analysis done by Checkmarx in August 2021, one of the most common IaC misconfigurations is having HTTP port 80 and ELB ports being left open to the public.]

How Should Developers Detect and Mitigate the Most Common IaC Risks?

As mentioned, most of the common risks can be mitigated by adhering to some common security best practices so it’s not all doom and gloom. Here is what you can start practicing:

• Spend some time with the tools: Spend time to fully understand how each tool works: its quirks, its open issues and its best practices. Participate in meetups and subscribe to events so you can learn from other industry experts. This will give you an advantage when trying to figure out how to perform tasks – simple and advanced – without compromising the security posture.
• Establish common engineering processes and best practices: Practice peer code reviews, CI/CD checks, linting, and verification. This can reduce the number of common accidents and mistakes that happen when you rush things.
• Use purpose-built IaC security tools: Look around for purpose-built tools like Checkmarx KICS (Keeping Infrastructure as Code Secure) that help you establish a secure and efficient infrastructure-as-code pipeline. The benefit of this tool is that you can configure it to match your organization’s policies due to its great extensibility and cloud provider coverage.

[If you are looking to get a quick look and better understanding on your current state, you can also quickly upload your IaC into Checkmarx new KICSaaS and get immediate results without having to download anything. Give it a try at: https://kics.checkmarx.net]

How and Where Can Developers and Security Teams Learn More About the Risks?

First and foremost, you can learn more about the risks of IaC by asking local IaC experts or official communities about some of their experiences with IaC. You may find that many of the issues they encounter prepare you for what to expect and what to look out for.

Furthermore, you should subscribe to reputable email lists and blogs from vendors that specialize in those areas, and offer tailored solutions like KICS for tackling most of the problems explored in this article.

Lastly, you should perform your own investigation to assess the pros and cons of each tool based on your own requirements and success criteria. The one-size-fits-all approach isn’t suitable for all lines of business. By performing all the necessary steps, you can hopefully mitigate most of the critical risks of using IaC tools.

—

Theo Despoudis is a Senior Software Engineer, a consultant and an experienced mentor. He has a keen interest in Open Source Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration. Follow him on Twitter @nerdokto. He can be contacted via http://www.techway.io/.

Download our Ultimate Guide to SCA here.

Orchestration, in this context, deals not only with the way microservices communicate or are composed, but also with infrastructural needs or specific configurations. While not long ago the provisioning of infrastructure and configuration was mostly a manual process, nowadays, and with the advent of the DevOps mindset, automation is pervasive and defined in code. Welcome to the era of Infrastructure as Code (IaC).
IaC establishes a methodology with tools and technology for infrastructure configuration and provisioning through code. It brings advantages such as: automation, idempotence (e.g., replication of infrastructure for testing and production), consistency, self-documentation, cost-reduction, to mention but a few. However, similarly to traditional software development, it is prone to issues like misconfigurations or security vulnerabilities which may jeopardize not just a specific application, but on a much larger scale, the entire business and its underlaying infrastructure.

Did anybody mention code and vulnerabilities?

Introducing KICS (Keeping Infrastructure as Code Secure): An open-source standalone engine powered by Checkmarx – a market leader in static code analysis – for detecting vulnerabilities, compliance issues, or misconfigurations from IaC in the context of cloud-native applications.  As of its launch date, KICS comes with 1000+ security rules (queries in Cx language), supporting Terraform, Kubernetes, Docker, AWS CloudFormation, and Ansible across multiple cloud providers (e.g., AWS, Google Cloud or Microsoft Azure).

How we made KICS!

In the beginning, KICS had only 50 queries, resided in a private repository, and existed as a standalone engine. At this time, the engine was able to read just a few IaC file types, convert them into an internal representation, and produce results in a JSON format.
To make it a product, an ambitious goal was set with the objective of reaching 1K REGO/OPA queries in less than three months, and making it completely open source in less than two. It could have been easy if the full team were already on board, but we were far from it.

KICS Rules – the Students Taskforce

Within two weeks we were able to recruit a group of talented students to join the team and focus on creating more rules developed using REGO.
REGO/OPA is a high-level declarative language for querying structured documents. For this reason, it was chosen to be the method for obtaining the IaC scan rules. The students picked up the development with ease using REGO and in less than a week of training, they were crafting rules and IaC samples – one true-positive and one true-negative per query –, following the recommended list of vulnerabilities and descriptions provided by the Checkmarx application security research team.

• Our target of creating 1000 rules was a major challenge. We adapted our processes and designs and created reusable libraries to avoid replication in our REGO code.

Ironically enough, with these in place, the bottleneck became the approval of Pull Requests rather than the development itself. By the deadline, not only the 1K queries milestone was reached, it was surpassed (~1.2K).

KICS Core – The Open-Source Quest

The initial focus of the core team was to make KICS completely open source.
With the close supervision and valuable pieces of advice from our OSS consultant, Lior Kaplan, who accompanied the project, we broke the dependencies with the private repository, rewrote the commit history to make it agreeable, and moved it to the public GitHub repository https://github.com/Checkmarx/kics, under Apache 2.0 license.
During this process, we created CI pipelines with GitHub Actions, keeping all KICS infrastructure within the Github environment. In no time, a battery of verifications was running, per Pull Request, in the pipeline. It addresses several quality aspects:

• Test coverage (with Codecov)
• Code quality (with SonarCloud and Codacy)
• Security (with CxSAST by Checkmarx and KICS itself, via KICS GitHub action)

All these verifications are surprisingly fast, taking about one minute – the time needed to have KICS ready for release after each successful Pull Request.
Provided that the quality grade passes in each CI step, KICS can be released at any time. Following open-source best practices, we produce:

• One nightly release, named with the hash of the corresponding commit.
• One official release every two weeks, using the SemVer standard.

Each KICS release includes bare sources, binaries for Windows, Linux, and MacOS, as well as a docker image made available on DockerHub.

KICS Documentation – Sharing the wealth

KICS works. It has a strong core able to analyze many types of IaC files and it has thousands of security rules. It is consistently released every two weeks; it is open source, and the team is proud of it! We just need to spread the word to the world!
For that matter, we built a website, and stored it in AWS. But that is only the beautiful landing page. The documentation site is generated on the fly, via MkDocs, from markdown files, and made available via GitHub pages.
We try to make KICS documentation as crystal-clear as possible, containing everything about the project, including roadmaps, tutorials on how to use, or how to contribute. Moreover, we set up a KICS community using Gitter. Some fellows started commenting outward, asking questions, and providing feedback right away.

KICS Management – Taming the beast

The team works in an agile way, following a Kanban approach. Managing the work this way becomes easy as we can naturally take advantage of GitHub integrated management capabilities.
We divided the work into projects and defined milestones to better organize the issues and requests to handle. Labels are applied to each opened issue allowing an easy understanding of their nature: bugs, features, security, query, enhancements, you name it.
To guide and better manage contributions from KICS users, we defined templates for bugs, features, new queries, and pull requests. With templates, we require important information and ultimately standardize the quality with which work is described.
Overall, KICS involves a multidisciplinary team of architects, developers, DevOps, and managers. It already has a few followers’ contributions and many more are expected soon.  And you, dear reader, are more than welcome to contribute as well. It does not matter whether it is by just following the project, providing feedback, opening issues or feature requests, submitting code changes, or just using KICS to keep your IaC secure.