OK, hands up. Who deploys containers with Kubernetes, using infrastructure-as-code (IaC) to automate its provisioning, security, and maintenance? Right, many of you do. Until recently, that meant many of you also used HashiCorp’s Terraform. After HashiCorp changed its open source license, many Terraform developers forked the code into OpenTofu, and quite a few of you moved to OpenTofu.
If you’re among the DevOps who made that move, you have been rewarded with OpenTofu 1.7.0. The release’s major highlight is the introduction of end-to-end state encryption. This feature ensures that a state file remains shielded from unauthorized access across any storage backend.
While that capability matters to anyone doing DevOps, it notably works hand-in-glove with DevSecOps. With Terraform, you were strongly encouraged to use HashiCorp Vault as a centralized secrets manager. With this OpenTofu release, you can secure encryption passphrases through environment variables or opt for robust key management systems such as AWS Key Management Service (KMS), GCP KMS, or OpenBao, the open-source Vault fork.
OpenTofu lacks a policy-as-code enforcement framework, which HashiCorp Sentinel provides for Terraform. For OpenTofu, it would be best to use third-party, open source programs such as Open Policy Agent (OPA) that can embed security policies directly alongside an OpenTofu configuration. You can then store your OpenTofu and OPA configurations in a version control system like Git. This ensures that infrastructure changes are tracked and auditable and that they can be easily rolled back if necessary.
Another innovative addition in OpenTofu 1.7.0 is dynamic provider-defined functions. This allows providers to supply resources and offer native functions that can be used directly within OpenTofu code. An OpenTofu-exclusive feature lets these providers dynamically create custom functions based on user configurations, fostering a seamless integration of other programming languages. The OpenTofu team encourages users to explore this feature with the experimental Lua and Go providers.
Additional features are also included. Among them is the ability to mark specific resources for removal from the state file while retaining the underlying infrastructure. The new OpenTofu version also introduces loopable import blocks to simplify the bulk import of resources, greatly aiding large-scale migrations.
Building on its legacy as a drop-in replacement for Terraform 1.5, OpenTofu 1.7.0 promises easy migration paths, offers detailed migration guides, and includes comprehensive documentation with examples. That suggests an easy upgrade if you’re using Terraform for DevSecOps.
Since its inception, the OpenTofu community has seen remarkable growth. Despite eschewing user tracking, the registry’s usage has surged to over a million requests daily, with a doubling in just the past month. The release has drawn 65 unique contributors and garnered 20,000 stars on GitHub, underscoring a vibrant community engagement with over 200 new issues and numerous pull requests since January.
In short, OpenTofu appears to be a solid choice for both IaC and DevSecOps deployments, regardless of what happens with Hashicorp, IBM and Terraform.
Filed Under: Blogs, Business of DevOps, Containers, DevOps and Open Technologies, DevSecOps, DevSecOps, Features, Infrastructure as Code, Most Read, News, Social – Facebook, Social – X Tagged With: devsecops, kubernetes, OPA, opentofu, policy as code, Terraform
Secure Coding Practices
Step 1 of 7
14%
Does your organization currently implement secure guardrails in the software development process?(Required)
Yes, extensively across all projects
Yes, but only in specific projects or teams
In the process of implementation
No, but planning to in the near future
No, and no plans to implement
What are the biggest challenges you face in implementing secure guardrails within your development processes? (Select all that apply)(Required)
Lack of awareness or understanding
Technical difficulties in integration
Resistance from development teams
Lack of suitable tools
Cost constraints
Other
Other, tell us more:
How effective do you find secure guardrails in preventing security vulnerabilities in your projects? Rate on a scale from 1 (Not effective) to 5 (Highly effective)(Required)
1
2
3
4
5
To what extent are your secure guardrails automated?(Required)
Fully automated
Mostly automated with some manual processes
Equally automated and manual
Mostly manual with some automation
Entirely manual
What features do you prioritize in a secure guardrail solution? (Rank in order of importance)Ease of integration into existing workflowsComprehensive coverage of security vulnerabilitiesCustomizability for specific project needsMinimal impact on development speedActionable insights and recommendationsSupport for a wide range of programming languages and frameworks
What are your organization’s plans regarding the adoption or enhancement of secure guardrails within the next 12 months?(Required)
Expand the use of secure guardrails to more projects
Enhance the capabilities of existing secure guardrails
Maintain current level of secure guardrail use without changes
Reduce reliance on secure guardrails
No plans related to secure guardrails
What best describes your primary role?(Required)
Security Engineer
DevOps Engineer
Platform Engineer
Security champion on the development team
Software Developer
CISO (or equivalent)
Sr. Management (CEO, CTO, CIO, CPO, VP)
Manager, Director
Other
Δ
