Terraform by HashiCorp is a leading tool for DevOps engineers and cloud architects. This powerful Infrastructure as Code (IaC) tool enables DevOps to define and provision cloud infrastructure using a high-level configuration language. At the heart of Terraform’s functionality are providers. Providers are essentially plugins that interact with the APIs of cloud services, allowing Terraform to manage a wide range of resources across different platforms.
This blog outlines the potential risks of Terraform providers.
Note: An earlier version of this post mistakenly referenced a module provided by Cloud Posse as a potential attack vector. We wish to clarify that Cloud Posse’s module is not a Provider and the module does not contain any known security vulnerabilities. Our use of it as an example was misguided, and we apologize for any confusion.
Understanding Terraform providers & their risks
Terraform providers streamline and automate cloud infrastructure management, allowing for quick deployment and easy integration of services from providers like AWS, Google Cloud and Azure.
To install Terraform providers, the package of the provider is auto downloaded. Below is an example of a simple configuration block in a Terraform script that downloads the AWS provider for managing resources in the US West (Oregon) region:
provider "aws" {
region = "us-west-2"
}
As you can see, when Terraform initializes this configuration with the terraform init command, it automatically downloads the AWS provider plugin from the Terraform Registry.
The convenience of these plugins means DevOps is using them on a daily basis, often without properly vetting them for vulnerabilities or other weaknesses. While providers owned and maintained by HashiCorp and major cloud vendors generally follow strict security standards, community-maintained providers vary significantly in quality and security. HashiCorp themselves group providers into three tiers:
- Official: Official providers are owned and maintained by HashiCorp.
- Partner: Partner providers are owned and maintained by a technology company that has gone through a partner onboarding process and maintain a direct partnership with HashiCorp. Partner providers are actively supported by the publishing organization.
- Community: Community providers are published and maintained by individual contributors.
Hashicorp’s official recommendation is to only use official and partner providers within your Terraform configuration. However, there are thousands of community providers in use, many with download numbers in the millions, that could expose an organization’s Terraform and CI/CD pipeline to security risks. Further, while community providers are the most risky, even trusted providers have known vulnerabilities and exploits.
As many well known and widely-used providers have known critical vulnerabilities, these can serve as an attack vector for threat actors with remote or physical access to the CI/CD. This can be achieved by gaining control of the code repositories, but this is quite difficult, as code repositories are usually pretty guarded. However, attackers can also gain access from outside of the repositories. For example, Terraform access can be accomplished where the state files are being stored in an S3 bucket, which is pretty common. Many times, state files are not as secure as they should be, but based on our experience, access rights are mostly read only for unauthorized users.
Malicious modules and providers
Threat actors can craft and publish malicious modules and providers, which can act as full-blown malware. Malicious modules can also be used to exploit known provider’s vulnerabilities. The malicious module inherits the permissions of the provider that runs it, which makes it important to understand and closely manage provider permissions.
Attackers can lure potential victims to use malicious modules or providers in several ways. Very similar to other marketplaces and third-party malicious apps, Terraform modules and providers can be published to where Terraform users frequently source them:
- Terraform Registry: The attacker submits the module or provider to the official Terraform Registry, providing a detailed description and documentation.
- GitHub Repository: The attacker creates a public GitHub Repository for the module or provider, ensuring it appears professional and trustworthy. They might include fake stars and forks.
Why is this important?
Attractive target: There are many ways threat actors can leverage CI/CD systems to take full control over your cloud environment and Terraform is one of the top crown jewels. DevOps and Platform teams will often leverage the great capabilities of providers and modules which are another potential “supply-chain” risk. Any malicious or vulnerable third party used by Terraform to deploy cloud assets can lead to a server impact even though the probability of such exploitation is low.
Major blind-spot: Providers are often not being vetted or scanned for vulnerabilities as part of the SDLC and Application Security flows. Commonly used IAC scanners are mainly focused on misconfigurations and do not cover vulnerability scans for those third parties.
Manual remediation: Remediation of third-party vulnerabilities was and still is a painful and manual process. DevOps team are already busy, focusing on fixing critical misconfigurations and adding more tickets to their workload doesn’t seem possible.
Best practices & mitigation
Due diligence: Before using a provider, do your homework. Look into the provider’s documentation, its source code (if available) and feedback from the community. This investigation can reveal a lot about the provider’s reliability and security posture.
Regular scanning of cloud repositories: To mitigate risks, it’s essential to regularly scan your cloud repositories. Use security tools like Trivy, to scan provider repositories and code for vulnerabilities.
Version pinning: To avoid unexpected updates that might introduce vulnerabilities, pin the version of your providers in your Terraform configurations.
provider "aws" {
version = "~> 3.27"
region = "us-west-2"
}
This code snippet ensures that Terraform uses only the specified version or patch updates within a minor version, helping to maintain consistency and security.
Auditing and monitoring: Regularly audit your Terraform plans and state files for any misconfigurations or unexpected changes. Tools like Terraform’s plan command or external security scanners can be invaluable here.
IaC security tools: Utilize Terraform-specific security tools, such as tfsec or checkov, to scan your configurations for potential security issues.
Conclusion
The power and convenience of Terraform providers are undeniable, but so are the security risks they pose if not properly managed. By understanding these risks and adopting a mindful approach to using providers, we can significantly mitigate potential threats to our cloud infrastructure.
As part of the broader Terraform and cloud security community, it’s also within our power to contribute towards safer practices. Reporting security issues, contributing to the development of providers, or even creating more secure alternatives, are all ways we can make a difference.
To learn more about how ZEST is helping organizations resolve cloud risks, reach out to our team.
