Bridgecrew: Misconfigured Terraform Modules Are a Security Issue
As many as half of all community-built Terraform modules available for download are misconfigured, opening the path for potential security breaches in infrastructure-as-code-driven systems, according to a new report from developer-focused security vendor Bridgecrew.
“Most of the market actually relies on public registry modules. And if they don’t have any controls in place to either analyze them systematically or by a human who has proficient knowledge of potential harmful misconfigurations in Terraform, those types of findings just get lost,” said Guy Eisenkot, a Bridgecrew co-founder and vice president of product, in an interview with The New Stack. “Some of those misconfigurations that eventually can result in data breaches can be very easily prevented using more secure modules.”
An analysis published in Bridgecrew’s “State of Open Source Terraform Security” report shows that 44% of the 2,600 modules for Amazon Web Services, Azure and Google Cloud support were misconfigured when Bridgecrew assessed how they match up again CIS benchmarks.
The problems are not in obscure configurations. In fact, 56% of the modules that have ever been downloaded contain what is now considered a misconfiguration, with the newest modules not improving significantly.
And this problem seems to be growing worse as Terraform continues to be more widely adopted: there were 83% more modules in the registry in the second quarter of 2020, as compared to the first quarter of this year. And growth has accelerated further since the data was collected in June. Overall, the developer-focused security firm found 15 million misconfigured modules have been downloaded since 2017.
Managed by HashiCorp, the open source Terraform framework has been one of the building blocks of the emerging “infrastructure-as-code” concept for IT systems. Terraform provides a path to programmable infrastructure, in which resources can be deployed and managed, through an easily-to-understand declarative language. In addition to managing the Terraform project itself, HashiCorp also maintains the Terraform Registry, which is home to thousands of modules, self-contained packages of Terraform configurations maintained by HashiCorp, cloud providers, and community contributors under common open source licenses.
But while organizations and cloud providers investigate the use of Terraform and other infrastructure-as-code tools, they may forget to put security checks in place as they move these prototypes into production.
According to Bridgecrew, a majority of its checks failed because the modules’ optional arguments for enhancing data security and traceability were not defined. Three-quarters of the registry’s modules are for AWS, but other cloud providers are beginning to catch up. The handling of S3 storage is particularly troublesome. A misconfigured module to create an Elastic Kubernetes (EKS) had been among the most downloaded, although a newer version is now available.
“In a configuration language like Terraform, you can optionally input arguments to configure your module to do something that’s very specific and customized to what you need to do. Even highly scaled Terraform engineers won’t even know all the potential attributes and arguments you can attach to a potential resource,” Eisenkot said. “What the language eventually requires is a set of mandatory fields to get it up and running and a set of non-mandatory optional fields that would go a long way in terms of hardening and restricting potential access to that resource.”
In response to the report, a HashiCorp spokesperson replied:
The use of the word “misconfigurations” in the report suggests that some modules are incorrect, which is not necessarily the case. The challenge with the Bridgecrew report is that not all Terraform modules intend to codify best practices. Some modules are there only to package up provider functionality in a more convenient way, while still leaving it to the user of the module to make the appropriate engineering tradeoffs. Some of the modules in the registry are authored by representatives of the cloud vendor they target and intended to encapsulate opinionated best practices, but that is not the goal of all of the registry modules. It’s certainly not a goal for Terraform Registry to allow users to totally outsource their engineering/design effort entirely to the module maintainers.
The Terraform Registry uses a ”verified” status to indicate HashiCorp has confirmed the authenticity of the module’s publisher, and that it is published by an active member of the HashiCorp Technology Partner Program, but this status does not indicate that HashiCorp has performed a review of the module’s contents.
The company does admit that one of the challenges of the open source version of Terraform open is that it lacks governance over how infrastructure-as-code is used. One of the advantages of the enterprise edition, the company notes, is the baked-in best practices and governance. “At HashiCorp, one of the things we focus on is bringing governance to organizations and teams while not sacrificing the benefits of open source. Terraform Cloud and Enterprise offerings help organizations with governance and compliance to avoid scenarios like those suggested in this report,” the spokesperson e-mailed.
Bridgecrew found that the most common misconfigurations were in modules created for backup and recovery, logging, and encryption categories. The lack of granular reporting in logging, for instance, could hamper investigations of security breaches. Likewise, the lack of backup and recovery protocols could severely slow the user’s ability to restore systems should they be incapacitated. Errors in networking modules could leave the whole system open to attack from the Internet.
For the job, Bridgecrew used its flagship Bridgecrew Platform, a self-serve utility that scans and fixes declarative code, which can draw automatically from the user’s GitHub account or other repositories. It covers not only Terraform but also Kubernetes, the Serverless framework, ARM templates and others. It relies on a number of scanners, including Bridgecrew’s own open source scanner Checkov.
Source: Bridgecrew’s “State of Open Source Terraform Security”
From Bridgecrew’s perspective, this lack of attention to security is proof that for many companies do not recognize security for infrastructure-as-code security is not yet a top priority, though the report did note that industry standards are improving, and cloud providers are attempting to educate their users on how to secure their deployments.
The report does not address the seriousness of the issues. Unlike with security vulnerabilities, there is no common system to rank how dangerous a misconfiguration can be.
There is a precedent for managing community resources securely: Several years ago, Docker Hub became enormously popular as a central repository of container images, but it soon became clear that unverified images often contained security vulnerabilities. Many commercial container registries came into existence to address that issue.
To be sure, the Terraform Registry does not pose the same types of risks as was seen in Docker Hub. Many of the modules are maintained by cloud providers and kept up to date. A companion to the registry is a listing of official and verified “providers,” which make logical abstractions of upstream APIs available that are responsible for API interactions and exposing resources. For now, these just encapsulate opinionated best practices. Simply put, modules in the registry allow you to successfully launch infrastructure as code, but the company makes no representations of how that will impact your security posture.
Bridgecrew offers a number of tips for minimizing configuration-based errors. An organization could create a service catalog model of pre-approved, tested modules. “It goes back to a process,” Eisenkot said. “Essentially, if the company is utilizing infrastructure-as-code, we highly recommend developing an internal process to vet and verify modules that come into the environment in the same way as you would do new open source packages that are introduced to the environment.”
Other tips: Developers could use a pre-commit hook scanner or a linter to capture errors during coding. A lightweight CI/CD job could flag most errors for the code owner.
Amazon Web Services, Bridgecrew and HashiCorp are sponsors of The New Stack.
Feature image via Flickr.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
