OpenTofu 实现 state 加密，未来将如何发展_AI阅读总结 — 包阅AI

When OpenTofu was first announced, a common refrain from the community was, “If you deliver state encryption, we’ll migrate.” Lo and behold, the much-awaited state encryption feature has shipped in OpenTofu v1.7. We recently compiled a list of reasons now is the time to consider migrating to OpenTofu, and this is just one more reason to consider.

This feature request has languished in the Terraform backlog since 2016, sparking extensive discussions within the community about its critical importance. That said, despite the outspoken requests for its implementation, the feature has not been delivered in any Terraform version.

A lot of skepticism was witnessed when OpenTofu was initially announced with much of the community feedback being — and I’m paraphrasing here — “let’s wait and see.”

Achieving the GA milestone was remarkable, coming just a few months after the fork announcement in August 2023. Today, we are proud to deliver one of the most anticipated features the Terraform community has been waiting for — a major feature enhancement just several months after the OpenTofu 1.6 GA milestone.

What Is State Encryption and Why Should I Care?

State files in Terraform (and similar tools) often contain sensitive information, including access keys — which if left unencrypted, pose a significant security risk.

When plain-text state files are unencrypted as they were until OpenTofu 1.7, anyone with access to these files can potentially exploit them, leading to unauthorized access and data breaches. Encrypting these state files secures data at rest and prevents unauthorized access. Daniel Grzelak, who initially wrote the state encryption code for Terraform, underscored this point during a recent episode of my IaC podcast. He shares an experience where a plain-text Terraform state file in an S3 bucket led to security vulnerabilities in an organization’s AWS account.

This is just one example of many potential attacks on Terraform. Others include changing resource references in state files, leading to unintended resource deletions or modifications, or inserting a custom provider reference to execute malicious code during the Terraform plan phase, compromising the CI/CD pipeline.

While state encryption can’t prevent all types of these attacks, it will ensure the data is sealed in the event of a breach, safeguarding the sensitive information inside.

The risks are compounded when we take a look at the excessive permissions in CI/CD pipelines in modern engineering organizations, such as those used in GitHub actions for Terraform deployments.

This alone can expose sensitive infrastructure to unauthorized access, which is also due to the fact that security teams often have less involvement in CI/CD pipelines, leading to developers and engineers setting up security without full understanding, increasing security risks.

That is why state encryption was an early and obvious feature request in OpenTofu, and its implementation offers the practical benefits of enhancing security for all its users.

The introduction of state file encryption in OpenTofu will now provide an added layer of security aimed at preventing attackers from being able to exploit plain-text credentials and should be considered a fundamental aspect of automation and scalability to effectively mitigate risks.

Why Hasn’t State Encryption Been Delivered Before?

Opinions vary on why state encryption was never prioritized in Terraform versions. This issue was even the subject of a recent discussion between Mitchell Hashimoto, HashiCorp’s co-founder and Terraform co-creator, and Adam Jacob, Chef’s co-founder and now co-founder of System Initiative.

I listened to this one! Just a couple points from me:

You said I didn’t like Chef! That’s not true and I hope I never said that. I used Chef for at least 3 years before I started using Puppet (and for about the same amount of time). You know better than anyone that Chef was the…

— Mitchell Hashimoto (@mitchellh) April 26, 2024

Per this discussion, Mitchell Hashimoto notes that the existing code didn’t satisfy the threat model at Hashicorp, and remained festering in the backlog.

However, the community would argue that there has been long-standing speculation that the implementation of state encryption would cannibalize the Hashicorp business model.

By providing state encryption, Terraform state files could then be hosted in any cloud provider, like AWS S3 much more securely, whereas Terraform Cloud — which offers this state encryption built-in, was a primary business offering from the commercial side of the open source business.

It’s also quite interesting to note that the Terraform documentation explicitly directs users not to encrypt, despite all of the known security threats of leaving state files encrypted.

OpenTofu Version 1.7 — What Else Can We Get Excited About?

As the age-old adage says “actions speak louder than words”, and we are excited to see OpenTofu delivering on the promise of evolving and maintaining the project.

It’s even more exciting to note that the primary considerations for any and all feature development is community-driven, and fostered by the foundation-hosted model.

This makes it possible to have all features be developed in a truly merit-based fashion and ensure that the features being shipped are the ones that are driven by community demand.

As early as the first weeks that OpenTofu was introduced, Terragrunt creator and OpenTofu core maintainer Yvgeny Brikman started tinkering with this high-demand feature request to showcase the proactive efforts towards delivering state encryption, see this post on LinkedIn with the early teasers.

This however is only one single feature in a continuously pruned and maintained list of feature requests and issues being opened by our growing community of enthusiasts.

Many more popular and high-demand features are being evaluated and implemented, from dynamic provider configuration assignment to supporting OCI registries, through supporting OpenTofu in the Visual Studio Code language server.

You can track the most popular feature requests in the project’s repo or on our community Slack (link), and suggest your own if you’re ready.

Will the Projects Reunite?

Of course, we can’t ignore the elephant in the room.In our previous post, where we spoke about 1.6 being a drop-in replacement for Terraform, and how it really has never been easier to migrate. Now is the time to acknowledge the expected divergence between Terraform and OpenTofu. This is particularly true with the recent acquisition announcement by IBM.

Since the acquisition announcement, there has been a lot of discussion about whether OpenTofu and Terraform will reunite.The OpenTofu governing board believes that vendor-neutrality has greatly benefited the project in its short lifespan. With a strong, growing, and engaged community, we expect the project to continue flourishing.

We are even seeing early signs similar to the OpenStack vs. AWS trend for major retail firms like Nike, Target and Walmart a few years back, that historically chose to host their infrastructure with OpenStack and not Amazon due to competitive considerations.

Oracle recently announced its departure from Terraform and the adoption of OpenTofu for Oracle E-Business Suite (EBS) Cloud Manager, which may be driven by similar considerations.

That’s not to say that IBM will not be a good steward of Terraform. If anything the fears surrounding the Red Hat acquisition proved to be unfounded, and IBM has demonstrated an impressive open source track record to date with both Red Hat, alongside many other interesting and innovative projects like IBM Z and LinuxOne.

Still, the foundation model has also proven to be a strong catalyst for much-needed innovation not only for the Terraform project, and this vendor-neutrality appears to be the right direction for the project’s long-term maintainability and sustainability.

We’re Just Getting Started

The implementation of state encryption in OpenTofu v1.7 marks the first of what we hope will be many significant milestones for this project whose roadmap reflects community-driven demand for the project’s ongoing development.

This feature is set to enhance OpenTofu security by protecting sensitive data within state files from unauthorized access and potential breaches, addressing a critical vulnerability.

This demonstrates OpenTofu’s commitment to community-driven development and rapid feature delivery, where this update not only fulfills a crucial security requirement but also reinforces the platform’s dedication to evolving in line with user priorities. As OpenTofu continues to diverge from Terraform, it promises a robust, secure future, with a focus on community-driven innovation.

If you are excited about state encryption and the other features we have planned, we welcome you to join our growing community, contribute ideas, and start exploring OpenTofu.