Description
This issue aims to open a discussion about extending terraform-provider-sops to support passing environment variables on a per-resource basis, in addition to the existing global provider-level approach. Both methods can coexist technically, and this proposal explores how they could complement each other.
The motivation is to enable more flexible configurations where different SOPS files may use distinct encryption methods, recipients, or secret engines — without having to re-initialize the entire provider context.
A working implementation of this idea is available here:
That implementation introduces env = {} at the resource level and safely injects these variables before executing the SOPS library, while preventing race conditions (via Go mutex) and maintaining compatibility with the existing provider behavior.
Background & Context
Previous related work:
Both proposals focus on global-level environment handling.
This one explores finer-grained control per resource, which could better fit certain multi-key or multi-engine setups.
Note
I’ve already implemented and tested this functionality in a private fork (including a release build).
If the maintainers feel this feature doesn’t align with the main provider’s direction, I’ll continue maintaining it separately — but it would be great to align design ideas and possibly merge the work upstream if there’s shared interest.
Description
This issue aims to open a discussion about extending terraform-provider-sops to support passing environment variables on a per-resource basis, in addition to the existing global provider-level approach. Both methods can coexist technically, and this proposal explores how they could complement each other.
The motivation is to enable more flexible configurations where different SOPS files may use distinct encryption methods, recipients, or secret engines — without having to re-initialize the entire provider context.
A working implementation of this idea is available here:
That implementation introduces
env = {}at the resource level and safely injects these variables before executing the SOPS library, while preventing race conditions (via Go mutex) and maintaining compatibility with the existing provider behavior.Background & Context
Previous related work:
Both proposals focus on global-level environment handling.
This one explores finer-grained control per resource, which could better fit certain multi-key or multi-engine setups.
Note
I’ve already implemented and tested this functionality in a private fork (including a release build).
If the maintainers feel this feature doesn’t align with the main provider’s direction, I’ll continue maintaining it separately — but it would be great to align design ideas and possibly merge the work upstream if there’s shared interest.