RFD - Switch from Terraform to OpenTofu

[marcelovilla]

Status	Accepted ✅
Author(s)	@Adam-D-Lewis @dcmcand @marcelovilla @viniciusdc
Date Created	24-10-2024
Date Last updated	25-10-2024
Decision deadline

Title

Switch from Terraform to OpenTofu

Summary

On August 10, 2023, HashiCorp announced a transition from MPL to BUSL in all of the new releases of their products. BUSL imposes limitations on how the software can be used commercially, which could introduce restrictions for Nebari users, depending on their use case. Given this uncertainty and in the spirit of open source, we have pinned the Terraform version downloaded automatically by Nebari during the deployment process to 1.5.7, the latest version before the licensing change. For reference, the most recent Terraform version at the time of writing this is 1.9.8.

Shortly after HashiCorp's announcement, several companies created a Terraform fork called OpenTofu (formerly named OpenTF), which is now a project managed by the Linux Foundation. OpenTofu is supposed to be a a drop-in replacement for Terraform. Hence, the proposal here is to switch from Terraform to OpenTofu.

User benefit

Switching to OpenTofu allows us to update a major dependency of Nebari without being affected by a license change.

Some of the benefits of being able to update this dependency include access to:

• Security improvements and Bug Fixes - We are currently pinned to an old version of Terraform. This means that we do not have access to newer bug fixes or security improvements released by Hashicorp. This switch would allow us to remain up to date with the latest version of OpenTofu ensuring that we benefit from all security patches and bug fixes
• New features - OpenTofu has already introduced new features that the community has long asked for, but Terraform never delivered. One example would be dynamic provider blocks. Since OpenTofu is a community project owned by the Linux Foundation it will very likely continue to innovate and add new features. This switch would allow us to use these new features.
• Better compatibility - By not upgrading, we risk conflicts as tooling stops supporting older versions of Terraform. This has not yet been an issue, but it is very likely to become an issue in the future. As Nebari relies on integrating a large number of open source projects, compatibility is very important for the project.

Design Proposal

OpenTofu acts as a drop-in replacement for Terraform and we just need to change the way we download and execute the binary. Changes would be relatively small and non-invasive and all the HCL files we currently have would stay the same.

Here is a draft PR used to investigate the feasibility of switching from Terraform to OpenTofu. It has been successfully tested in the following scenarios:

• Local deployment
• AWS deployment
• GCP deployment
• Upgrade of existing 2024.9.1 GCP deployment to nebari-dev/nebari@8f709da

Alternatives or approaches considered (if any)

• Keep using Terraform 1.5.7 indefinitely
• Switch to a newer version of Terraform and

Neither of these alternatives seems realistic to me. While it's true that nothing is currently being blocked by our inability to upgrade Terraform, I don't see how staying behind could be sustainable in the long run. Over time, the gap between our version and the latest release will widen, potentially leading to security vulnerabilities, compatibility issues, and missed opportunities for improvements and new features.

As for the second option, keeping a permissive license offers several benefits over a restrictive one, such as a wider community adoption and contribution, fewer legal and compliance concerns, and better compatibility with other open source projects.

Best practices

User impact

This implementation wouldn't have user-facing changes and it would be rolled out in a new Nebari version, without users having to do anything besides upgrading.

Unresolved questions

[dcmcand]

In my opinion, there are almost no downsides here and a ton of upsides. I fully support this transition at this time. Initially I didn't want to because at the time OpenTofu was so new that I wanted to ensure that it was going to actually be around. At this point, there has been sufficient community adoption and support that I think this is a very safe transition that will take minimal effort.

[dharhas]

Notes:

OpenTofu will not have its own providers. Terraform providers have not altered their licenses, and the potential for such a change is virtually zero. OpenTofu works with the current Terraform providers, but it uses a separate registry.

Also there are some interesting security features that are available in OpenTofu now, like state encryption - https://opentofu.org/blog/opentofu-1-7-0/

[tylergraff]

Comments from the JATIC Security Team.
BLUF: OpenTofu is ok for now, but issues may develop as it diverges from Terraform over time.

---

There's very little official (DoD) guidance regarding OpenTofu in particular. There isn't much official regulation for open source technology as a whole as it's a relatively new endeavor when it comes to building guidance for open source within the DoD. There are some best practices to keep in mind when it comes to open source (OS) technology that would be applicable to OpenTofu (and any OS tools).
DoD Memo regarding OSS: https://dodcio.defense.gov/portals/0/documents/library/softwaredev-opensource.pdf

Potential Risks:
Version drift (features) - OpenTofu is currently a fork of Terraform and is very similar but as upgrades are made to Terraform, some of those upgrades may not make it to OpenTofu. Depending on the upgrade, this may present a security risk
Software Components - since OpenTofu will be community driven, there is a possibility of unvetted libraries and components making their way into the tool. The DoD has a requirement of scanning and keeping a detailed record of the software supply chain which can help identify future issues but will not prevent them
Maintenance (patching and efficiency) - Maintenance of the tool will be purely community driven. While this has its pros, this relies heavily on the assumption that there will be regular maintenance (during the lifecycle of Nebari) which may not be the case. Out of date components may introduce a security risk to the system and not having a dedicated security team to monitor changes and provide updates may be risky in the long run (as with all open-source tools and applications).

[dcmcand]

Speaking to these risks:

1. Version Drift - I don't see this as an issue. Open Tofu is it's own project. The risk is that OpenTofu will not supply security patches for it's product, but that is an issue with any project. I don't see any additional risk here.
2. Given the prevalence of third party libaries, this is an issue with any software project. The fact that OpenTofu is open to community contributions actually makes this less of a risk than with Terraform.
3. It isn't accurate to say that maintenance is exclusively community driven. There are a number of companies (Harness, Spacelift, etc) that have committed to providing multiple FTE's to opentofu maintenance. You can see companies that have committed to support OpenTofu at https://opentofu.org/supporters/. OpenTofu actually has considerably more corporate support than Nebari does!