Since the stable release in January, the OpenTofu community and the core team have been collaborating closely on the next wave of improvements. Now OpenTofu v1.7 is here, and it brings with it multiple new upgrades, with highlights like:
- State file encryption (!)
- Loopable import blocks
- Removed block
- Provider-defined functions
and more.
Exciting times! Let’s dive right in.
Finally Here: State File Encryption
The launch of OpenTofu 1.7 brings a highly anticipated update: state file encryption. This addition, among the first requested features by the OpenTofu community, now provides users with a critical security capability that has been eagerly awaited for years.
With state encryption, OpenTofu will encrypt the state data at rest. This ensures that, in case of unauthorized access, sensitive information, including passwords, user tokens, and private keys, will not be exposed in plaintext.
For additional context about the importance of state file encryption, and state file security in general, check out this excellent post by Daniel Grzelak: “Hacking Terraform State for Privilege Escalation”.
We also recently had the pleasure of hosting Daniel on The IaC Podcast, which you can listen to here:
How to Configure State File Encryption
To enable and configure state file encryption, OpenTofu users will need to add an encryption block to their code (or use [.code]TF_ENCRYPTION[.code] variable) and specify the following:
- [.code]key_provider[.code], which specifies the provider for the encryption key. At the time of the release, the supported providers include PBKDF2, AWS KMS, GCP KMS, and OpenBao.
- [.code]method[.code] that determines the encryption method to be used. Currently, the primary supported option is AES-GCM, allowing the use of 16, 24, or 32-byte keys.
Here is an example of how this may look:
State encryption can be implemented in both new and existing projects, and users also have the option to define a fallback configuration, facilitating automatic rollover. Furthermore, this feature enables the encryption of remote state files.
To learn more visit OpenTofu official docs
Importantly, by delivering the feature as an opt-in, we ensure that OpenTofu remains interoperable with Terraform v1.5, enabling it to continue to act as a drop-in replacement.
Other Improvements
In addition to state encryption, OpenTofu v1.7 introduces several other new features, which boost efficiency through added flexibility and new automation options.
There include:
Loopable Import Blocks with for_each
OpenTofu 1.7 introduces support for the for_each statement within import blocks. This allows developers to import multiple instances of a resource in a single block, making it easier to handle bulk operations.
For example:
Removed Block
OpenTofu now supports a removed block, enabling users to tag resources for removal without destroying the corresponding infrastructure object.
Provider-defined Functions
The v1.7 release incorporates support for provider-defined functions, including functions that can be dynamically defined based on your OpenTofu configurations.
What’s Next? You Decide
As we announce the v1.7 release, we are already setting our sights on the next OpenTofu version.
If you have a feature you would like to see in the next version, please don't hesitate to open an issue or reach out to us on Slack.
Since the stable release in January, the OpenTofu community and the core team have been collaborating closely on the next wave of improvements. Now OpenTofu v1.7 is here, and it brings with it multiple new upgrades, with highlights like:
- State file encryption (!)
- Loopable import blocks
- Removed block
- Provider-defined functions
and more.
Exciting times! Let’s dive right in.
Finally Here: State File Encryption
The launch of OpenTofu 1.7 brings a highly anticipated update: state file encryption. This addition, among the first requested features by the OpenTofu community, now provides users with a critical security capability that has been eagerly awaited for years.
With state encryption, OpenTofu will encrypt the state data at rest. This ensures that, in case of unauthorized access, sensitive information, including passwords, user tokens, and private keys, will not be exposed in plaintext.
For additional context about the importance of state file encryption, and state file security in general, check out this excellent post by Daniel Grzelak: “Hacking Terraform State for Privilege Escalation”.
We also recently had the pleasure of hosting Daniel on The IaC Podcast, which you can listen to here:
How to Configure State File Encryption
To enable and configure state file encryption, OpenTofu users will need to add an encryption block to their code (or use [.code]TF_ENCRYPTION[.code] variable) and specify the following:
- [.code]key_provider[.code], which specifies the provider for the encryption key. At the time of the release, the supported providers include PBKDF2, AWS KMS, GCP KMS, and OpenBao.
- [.code]method[.code] that determines the encryption method to be used. Currently, the primary supported option is AES-GCM, allowing the use of 16, 24, or 32-byte keys.
Here is an example of how this may look:
State encryption can be implemented in both new and existing projects, and users also have the option to define a fallback configuration, facilitating automatic rollover. Furthermore, this feature enables the encryption of remote state files.
To learn more visit OpenTofu official docs
Importantly, by delivering the feature as an opt-in, we ensure that OpenTofu remains interoperable with Terraform v1.5, enabling it to continue to act as a drop-in replacement.
Other Improvements
In addition to state encryption, OpenTofu v1.7 introduces several other new features, which boost efficiency through added flexibility and new automation options.
There include:
Loopable Import Blocks with for_each
OpenTofu 1.7 introduces support for the for_each statement within import blocks. This allows developers to import multiple instances of a resource in a single block, making it easier to handle bulk operations.
For example:
Removed Block
OpenTofu now supports a removed block, enabling users to tag resources for removal without destroying the corresponding infrastructure object.
Provider-defined Functions
The v1.7 release incorporates support for provider-defined functions, including functions that can be dynamically defined based on your OpenTofu configurations.
What’s Next? You Decide
As we announce the v1.7 release, we are already setting our sights on the next OpenTofu version.
If you have a feature you would like to see in the next version, please don't hesitate to open an issue or reach out to us on Slack.