Hacker News Reader

Comment by leetrout | Hacker News Reader

My previous team argued with me when i said to avoid using terraform with vault with our state in S3.

I eventually got my way after 18 months and found out it was really bad - hard coded s3 access keys were floating around that could read any bucket and they had used terraform with vault and that had pulled all sorts of root level creds into the plain text state files.

Lots of other ways to control this risk but I removed vault from TF.

View on HN

opentofu is solving this with proper state encryption support: https://github.com/opentofu/opentofu/issues/874

Do you think a feature like this is tied to distancing OpenTofu from Hashicorp, e.g., AWS & friends have less incentive to do enterprise feature gating around security?

State Encryption was one of those long requested features[0] (I had it on my ideas list for years[1]) that Hashicorp didn't have much incentive to build. I don't think it has to with distancing opentofu as such, but the opentofu team prioritizing the right things that customers actually need.

[0]: https://github.com/hashicorp/terraform/issues/9556

[1]: https://github.com/captn3m0/ideas#-mars-terraform-remote-htt...

Interesting!

The 'much incentive' part is the interesting thing to me. Hashicorp did build encryption-at-rest for state into their paid remote cloud service. They explicitly recommend using the paid service instead when security is required, and instead of having both versions secure, the paid form simply disables the local one [1], drawing a strong line here between paid/secure and unpaid/insecure.

So I'm wondering if that created a disincentive, from a perspective of enterprises upselling for security & compliance. OpenTofu community members aren't relying on selling a remote management service, and when a cloud provider, more usage in general is better, and that includes security for everyone. I can be off, so not quite clear to me the more I look.

[1] https://developer.hashicorp.com/terraform/language/state/sen...

With a tool like Terraform, when is security not required?

Encryption at rest of local terraform state seems beyond the threat model & compliance needs of a pre-PMF consumer startup

It's a lot harder to be an enterprise company or b2b startup (SOC2) and brush that off in front of knowledgeable auditors. I'm guessing most would miss it and rely on self-reporting, which in turn raises how 'loud' this issue is for most OSS terraform users.

We aren't heavy terraform users, so I'm not sure of the threat modeling here. Understanding these kinds of product decisions and OSS security ramifications is a pet interest of mine, and this is a fascinating one!

Hard agree. When I started my company we were playing with Terraform but left it pretty early and before taking anything into production because of the issues with state management and security.

We moved on, but there are areas where I wouldn’t mind poking at it. I’ve been thinking OpenTofu is where I’d start afresh with TF.

State encryption won't solve this problem, it will simply move the key management problem further down the stack. I.e. to the users who are least equipped to deal with it.

The problem is storing anything sensitive at all in terraform. Terraform is terrible for secrets.

Was that a fundamental problem with TerraForm or just an implementation issue?

The thing is that most HN folks, competent IT people see tools like Terraform, ansible, docker et al as neat tools that simplify and speed up annoying chores, so you get to spend your time on solving actual problems. What it means to managers is that task X has become so easy that you can hire complete idiots who would've failed without the tool but now manage to cobble something together quickly that appears to work well. Except you now have passwords and keys in repos, open s3 buckets, ...

Reply on news.ycombinator.com