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.
