We just recently adopted this and it's crazy to me how I spent years just copying around gitignored .env files and sharing 1password links. Highly underrated tool.
For a long time up until about a couple of years ago the project was stagnated and was missing some pretty critical features. I'd say it was only halfway usable until then and it doesn't have near the ecosystem that things like Hashicorp Vault does. But for my self hosted infra stuff it is perfect. It just really doesn't gel well with compliance frameworks and audits, mainly because the auditability of the solution goes out the window the second someone is able to decrypt the secret - its access patterns are untraceable. These auditors really prefer to see a situation where access to the secret is tightly controlled and audited on rotation and sops, by nature of how it works, cannot really easily offer that.
Sops can natively handle .env files. All you need to apply them to your process is a small wrapper script that sources the decrypted file before invoking your command.
There's a lot of gotcha bundled into this statement. It is true what you say, but it also hides away the nightmare of shell escaping bullshit that comes with the .env format the second you have to have some sort of transformation on the data that is orthogonal to the normal decryption path. I think that now they have a better story around some of the edge cases but if you go into SOPS you will see several issues around how the .env file format is just a complete nightmare with crazy escaped values such as a Google Service Account JSON.
The way I got around this on my own stuff is just to have a policy that all sops secrets have to be base64 encoded before the encryption hits them. That seems to solve basically every piping issue you could hit. Works super well with kubernetes, who supports native base64 encoded secrets, so you just take the value and inject it in, using data: instead of stringData: in the manifest of the created secret.
We just recently adopted this and it's crazy to me how I spent years just copying around gitignored .env files and sharing 1password links. Highly underrated tool.
For a long time up until about a couple of years ago the project was stagnated and was missing some pretty critical features. I'd say it was only halfway usable until then and it doesn't have near the ecosystem that things like Hashicorp Vault does. But for my self hosted infra stuff it is perfect. It just really doesn't gel well with compliance frameworks and audits, mainly because the auditability of the solution goes out the window the second someone is able to decrypt the secret - its access patterns are untraceable. These auditors really prefer to see a situation where access to the secret is tightly controlled and audited on rotation and sops, by nature of how it works, cannot really easily offer that.
Has done "wat" for years?
I use sops for encrypting yaml files. But how does it replace .env or other ENV var setters/holders?
Sops can natively handle .env files. All you need to apply them to your process is a small wrapper script that sources the decrypted file before invoking your command.
There's a lot of gotcha bundled into this statement. It is true what you say, but it also hides away the nightmare of shell escaping bullshit that comes with the .env format the second you have to have some sort of transformation on the data that is orthogonal to the normal decryption path. I think that now they have a better story around some of the edge cases but if you go into SOPS you will see several issues around how the .env file format is just a complete nightmare with crazy escaped values such as a Google Service Account JSON.
The way I got around this on my own stuff is just to have a policy that all sops secrets have to be base64 encoded before the encryption hits them. That seems to solve basically every piping issue you could hit. Works super well with kubernetes, who supports native base64 encoded secrets, so you just take the value and inject it in, using data: instead of stringData: in the manifest of the created secret.
FWIW, I looked into it myself too, and found e.g. this direnv setup:
https://github.com/direnv/direnv/wiki/Sops
Yeah, if you want .env-ish behavior, use sops + age. Or dotenvx.
Literally the first thing I though of.
Came to say this.