Encryption of secrets stored in state and or support for a would be an excellent first fork feature to pull ahead. Maybe something that supports backends like AWS KMS (for encryption) or AWS Secret Manager (for storing/retrieving ) secrets.
Stringing together resources to pull from a secrets manager and still having the secrets stored plainly in state is enormously frustrating. We aren’t all living in a nirvana of fast rotating out of band secrets.
This is actually a feature I'd love OpenTF to have and am quite passionate about, personally. My plan is to submit it once we have the RFC process in place.
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
> > Maybe something that supports backends like AWS KMS (for encryption) or AWS Secret Manager (for storing/retrieving ) secrets.
> This is actually a feature I'd love OpenTF to have and am quite passionate about, personally
You're probably already aware, but SOPS¹ kinda fits the bill for integration here perfectly.
It supports local secrets as well as encryption via keys stored with all the big cloud providers, and it's already battle-tested as it is used heavily at Mozilla (it comes from there).
Additionally, like OpenTF, SOPS is maintained independently of any single corporation, written in Go, and distributed under the MPL-2.0 license. On its face, it seems like a match made in heaven.
SOPS is a great tool and could be a pretty killer starting point for this stuff!
Pure personal speculation here, even though I'm one of the OpenTF folks. If one wanted to make secret encryption ultimately flexible, it could become a type of extension like provider, which would work as a sidecar and simply encrypt and decrypt each secret thrown at it. It should be possible to wrap SOPS into one such plugin.
I was kind of thinking the same thing, and that SOPS would be a good fit here because (as hacky as that mechanism is!) SOPS could be downloaded as a little static Go executable during `terraform init` just like providers are. `age`, too.
And yeah, a plugin interface would be great for lower coupling, and the provider interface seems like a model that could basically be copied here. :)
Yes, and perhaps backends could work in a similar way, too?
One other thing was that I was thinking whether these plugins really need to be local. A remote gRPC server could possibly work as well, I guess? Again, pure personal speculation.
In general, I think supporting local workflows is important for providing a good developer experience as well as maintaining a single source of truth (although I know being a purist about this is impossible when what we're doing is managing cloud environments!). So I think that it's an important option. Additionally, when you perform the encryption locally, you don't have to think so much about transmitting the cleartext secret to whatever server/program does the encryption, so that's nice.
But cloud-stored secrets are often an exception to single-source-of-truth and the preference for local workflows anyway, and some teams reasonably prefer other workflows. And a network boundary might be a natural place to put some secret sauce for a company like yours, or even just to give users the option of plugging into a centrally managed, shared environment— even if what is running on the remote end is self-hosted and source-available or even open-source.
Stringing together resources to pull from a secrets manager and still having the secrets stored plainly in state is enormously frustrating. We aren’t all living in a nirvana of fast rotating out of band secrets.