This blog post refers to the Silicon Chalet Meetup Infrastructure as code, best practices and pitfalls to avoid that I had the opportunity to present on 22/05/2025. At the end of the presentation, I specifically highlight the features available in both OpenTofu and Terraform that help safeguard sensitive data.
Don’t hesitate to take a look at the presentation to discover more!
Secrets… an endless loop#
When you’re working on Infrastructure as Code, also commonly known as IaC, it’s tricky to avoid the topic of secrets or sensitive information that you end up storing one day or another in the well-known state of Terraform or OpenTofu….
In both of these declarative languages, one of the main functions is to store the status of resources that have been deployed by the tool. This includes traditional resources such as networks and virtual machines, as well as API keys or database passwords that you want to deploy or inject into your applications or services.
One thing is for sure: the two tools mentioned above are evolving and have recently introduced internal mechanisms to protect or avoid storing this information in a crude way.
Since Terraform’s licence change two years ago, OpenTofu was developed and has gained popularity, largely driven by strong community support and recent enhancements that expanded its functionality. In particular, the state protection that Terraform publisher HashiCorp has always refused to implement in the open source version.
If you’re interested in all aspects of IaC languages, don’t hesitate to have a look at some best practices, not to mention the implementation of a CI/CD for Terraform or OpenTofu (only available in French for the last one).
Ready to discover what these two tools can do for you? Let’s get started!
OpenTofu#
OpenTofu? Yes! the latest IaC tool (well, not really…)!
I already introduced this tool in an post on creating resources in Cloudflare a few months ago.
To put things simply, OpenTofu is a derivative of version 1.6.x of Terraform before its licence was changed to a Business Source License two years ago.
This sudden change to the licence has no major consequences for most Terraform users, but it requires those offering services based on the tool to compensate its publisher. Nonetheless, it has caused the community to react strongly to the fact that a tool now used globally for deploying resources in production contexts can change its terms of use from one day to the next.
Therefore the Linux Foundation supports the project, the same organisation behind the CNCF and Kubernetes. Which means that the future of the tool is fairly safe.
In its two years of existence, OpenTofu has made steady progress in its adoption by end users, this is largely due to its responsiveness to the community and its implementation of features that have been requested for a very (very, very) long time in Terraform.
The first version, 1.7.0 adds state encryption. To me, this is clearly the biggest flaw in HashiCorp’s product.
It is extremely easy to set up and it can be interfaced with a passphrase or use an external Vault such as AWS KMS, Google Cloud KMS or OpenBao.
terraform {
encryption {
key_provider "pbkdf2" "encryption_key" {
passphrase = var.encryption_passphrase
}
method "aes_gcm" "encryption_method" {
keys = key_provider.pbkdf2.encryption_key
}
state {
method = method.aes_gcm.encryption_method
enforced = true
}
plan {
method = method.aes_gcm.encryption_method
enforced = true
}
}
}
Configuration example for plan and state encryption.
{"serial":1,"lineage":"fb7d17fe-...","meta":{"key_provider.pbkdf2.encryption_key":"eyJzYWx...","encryption_version":"v0"}
Content of an encrypted state.
OpenTofu’s life isn’t a bed of roses, with HashiCorp often keeping a close eye on its rivals’ developments, it has even gone as far as initiating legal action when it considers that the implementation of features is too close to its own.
As mentioned above, OpenTofu’s aim is to follow the wishes of the community, and this will continue while maintaining control over compatibility with Terraform, with the deep desire to help people migrate without hindrance.
Reducing OpenTofu to the encryption of its storage would be a little too reductive… Many changes have been made since then. You can see them in the documentation.
Terraform#
Over the last few years, Terraform has become the industry standard for infrastructure creation: its declarative language, the multiple providers for deploying resources, not to mention the use of a state to store the actions performed by the tool, have all contributed to its strength and popularity.
Terraform continues to grow, with the latest version v1.12.x released in the middle of May with, as always, a wide range of improvements.
But the feature I wanted to tell to you about came up with v1.10.x and has been enhanced in v1.11.x.
I’m referring, of course, to the possibility of making some of your resources ephemeral!
This enhancement from HashiCorp is a clear response to the state encryption offered by OpenTofu. You still can’t encrypt the state with Terraform, but you now have the option of avoiding saving sensitive resources or information.
This functionality is divided into two parts:
- The ephemeral resources with the keyword
ephemeral, require a real implementation of the provider within Terraform. For example, the provider tls provides the resourcetls_private_key.
ephemeral "tls_private_key" "this" {
algorithm = "ECDSA"
ecdsa_curve = "P384"
}
An example of an ephemeral resource.
The lifecycle is completely different from the resource block. In fact, an ephemeral resource only lasts during a plan or apply phase without persisting the result in the state. Terraform uses an open and close mechanism to access the resource and retrieve information temporarily.
- Write-only arguments are closely associated with ephemeral resources.
In fact, an ephemeral resource can only link its outputs to resources with fields suffixed with _wo.
Why is that? Quite simply because these parameters will not be stored in Terraform’s state or plan.
[...]
# kubernetes_secret_v1.this:
resource "kubernetes_secret_v1" "this" {
binary_data_wo = (write-only attribute)
data_wo = (write-only attribute)
data_wo_revision = 1
[...]
The binary_data_wo and data_wo fields are not visible in the state.
_wo_revision or _wo_version fields are mandatory if you want to inject a value into a _wo field. This is the only way to tell Terraform to modify the value if it is incremented.The retrieval and injection of sensitive values could use this type of mechanism to avoid duplicating information within the plan and state.
Be careful though, providers are starting to integrate the two features described above, but it still requires some more time before it becomes standard practice.
A definitive decision? Well, not really!#
What do you think? Encrypting the state or ephemeral resources? OpenTofu or Terraform?
Well I’ve got great news for you, OpenTofu gives an easily accessible preview of work for future releases, and, ephemeral resources will be coming in OpenTofu as part of v1.11.0.
A GitHub issue was raised a few months ago causing a huge reaction, which undoubtedly led the development team to plan its future integration.
A good reason to wait, but another reason to switch, don’t you think?
Demo time#
This demo was created for the Silicon Chalet Meetup and gives you the possibility to discover:
You can get it directly here:
To try out these two features you can, once the prerequisites have been met…
- Run the commands described in the README;
- Or use the
opentofu-demo.shorterraform-demo.shscripts, and let them guide you.
A few final words#
Security and sensitive data protection are very important issues, particularly in the context of a DevSecOps approach. Infrastructure as Code is no exception to the rule, and the emergence of a direct competitor to Terraform has given new momentum to the battle and the development of new features.
With Terraform, HashiCorp is seeking to stand out from the crowd without diluting its commercial offerings in the open source version. OpenTofu remains dedicated to responding to community feedback, even if that involves adopting popular concepts directly from Terraform.
The choice of a tool also lies in the functionalities it offers, and I’m personally convinced that state encryption has made a lot of companies move to OpenTofu. In fact, I’ve seen this happen with customers I work with as a consultant.
Even if OpenTofu is still young, it inherits Terraform’s past and therefore its maturity. Now it’s up to you to make a choice!