The TLDR is, first environment variables are visible to every process running as the same user on the system (try 'ps eww') and second they leak very easily in debug logs, etc.
We started developing Infisical for the majority of people using environment variables right now. We actually have some plans for accommodating for other more secure approaches very soon. Stay tuned.
Feel free to join our Slack for any updates: https://join.slack.com/t/infisical-users/shared_invite/zt-1k...
And `password` is still by far the most popular password.
Why not just call it environment management, and warn ENV is not secret, so you don't spread the wrongness?
The post strongly recommends storing the secret in a file instead of an environment variable, but it doesn't say anything about unmounting the secrets after initialization. Usually if you have access to one you also have access to the other. It also doesn't mention that you might not have any subprocess, or that if you do have a subprocess the subprocess might need the secrets.
If you're using containers to maintain the principle of least privilege, it's important to carefully examine everything that has access to the container, but having different levels of access within the container beyond what the programming language provides is a niche use case.
The programming language helps you know what the inputs, outputs, and side effects are - so you can be confident a module doesn't actually have access to things it doesn't need, even if writing some code would do it. Things like WebAssembly, vm2, and Deno are helping with that, and all are guarded against environment variable leakage.
Edit: For WebAssembly I looked into WASI and there are some explicit and implicit ways of providing environment variables. Gotta be careful with the implicit ones. There's this that can be used to give a WASM module access only to specific environment variables or none - don't call inherit_env https://docs.rs/wasmtime-wasi/0.21.0/wasmtime_wasi/struct.Wa... There is this that provides a convenience function for creating a WasiCtx that has access to all environment variables though: https://docs.rs/wasmtime-wasi/0.21.0/wasmtime_wasi/struct.Wa...
- some of these don't have a Web UI at all - which I think is very important
- some of these don't have integrations with 3rd party services
- some of these are only compatible with JS
- some of these are just so complicated so you need at least a week to figure them out :)
Why?
> some of these don't have integrations with 3rd party services
Like?
> some of these are only compatible with JS
What do you mean only compatible with JS?
> some of these are just so complicated so you need at least a week to figure them out :)
You could say the same about anything. So you want users to just trust yours but have to figure everyone elses out? If they had to understand yours from a more fundamental perspective I'd imagine yours would take just as long.
Note this still takes a dependency on the service.
It is important to understand the threat model in order to place the appropriate mitigations into the security architecture.
A tool will never solve a security problem by creating an optimal design. That requires someone with security knowledge. There are threat modeling tools that can help but only when the tools are used as designed.