Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: From dotenv to dotenvx – better config management

dotenvx.com

Post reply on HN
Print view View original

131–140 of 223 posts

Re: Show HN: From dotenv to dotenvx – better config management

#131

Post by curiousdeadcat »

ComputerGuru wrote: post #97
curiousdeadcat wrote: post #60

Earlier quoted context omitted.

I got so excited, but it doesn't seem to support multiple keys and seems overly eager to encourage people to leave a valuable key lying around on disk. So if a single dev machine is compromised, all of your prod secrets are exposed? I wish this were closer to sops with support for gpg and or ssh keys. Because sops is a great idea locked in a questionable codebase.

Happy to discuss a proposal to add asymmetric key support to the project in the GitHub issue tracker. Although I'm not sure how the security changes with an asymmetric key, as either way the worst case scenario is the same? Note that you don't have to leave the key "lying around" as you can secure it the same way you would an asymmetric key. And it certainly beats leaving the plaintext secrets themselves lying around…

Asymmetric keys mean you can you can have per-dev or per-team keys and allow one team to rotate them and resign them for all other consumers. I don't know how you'd do that with symmetric keys. This is an important feature of sops, imo.

It also means I can do things like seal them to a key that is stored in KeyVault and then allow the transparent retrieval of that key at runtime on Instances that have been given an identity with access.

This means that production secrets are sealed in place and only openable by effectively authenticated workloads.

And if you use sops-nix, this becomes a "setup once and never think about it ever again, ever" kind of operation.

Re: Show HN: From dotenv to dotenvx – better config management

#132

Post by bluelightning2k »

michaelmior wrote: post #48

With leaking secrets being such a big concern, it seems wise to require that secrets be encrypted to use dotenvx. That is, it will only work with encrypted secrets. As others have commented, this doesn't eliminate the risk entirely, but I think having a tool that doesn't support unencrypted secrets at all, although a bit less convenient, is a win.

Not all env vars are secrets. About half is just regular config. If mandatory how would it know what's a secret?

Re: Show HN: From dotenv to dotenvx – better config management

#133

Post by slt2021 »

cyberax wrote: post #116
slt2021 wrote: post #87

Earlier quoted context omitted.

it might be easier to just store and checkout a single decryption key that only devops people know, vs storing hundreds of secrets. while developers can move around their .env file across systems without worrying that they left plaintext secrets somewhere. also it allows adding new secrets without knowing decryption key - I think it is important for collaboration also most importantly: plaintext decrypted secrets are…

> it might be easier to just store and checkout a single decryption key that only devops people know, "Devops people know" means that the key must be some secret property. Or you need to use the key during the deployment artifact building pipeline, and then deploy the artifacts with clear-text secrets. > vs storing hundreds of secrets. Then serialize them to JSON or whatever. > also it allows adding new secrets witho…

encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk - I dont understand why you make it seem like it is a bad idea?

like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities??

as if directory traversal, path injection vulnerabilities, shell command injection, etc vulns that allow reading file from disk, don't exist?

Re: Show HN: From dotenv to dotenvx – better config management

#134

Post by skissane »

cimnine wrote: post #88

I think it's good advice to not pass secrets through environment variables. Env vars leak a lot. Think php_info, Sentry, java vm dumps, etc. Also, env vars leak into sub-processes if you don't pay extra attention. Instead, read secrets from a vault or from a file-system from _inside_ your process. See also [1] (or [2] which discusses [1]). Dotnet does this pretty good with user secrets [3]. [1] https://blog.diogomoni…

> Instead, read secrets from a vault or from a file-system from _inside_ your process.

I’ve never liked making secrets available on the filesystem. Lots of security vulnerabilities have turned up over the years that let an attacker read an arbitrary file. If retrieving secrets is a completely different API from normal file IO (e.g. inject a Unix domain socket into each container, and the software running on that container sends a request to that socket to get secrets), that is much less likely to happen.

Re: Show HN: From dotenv to dotenvx – better config management

#135

Post by slt2021 »

rhplus wrote: post #23
boxed wrote: post #3

I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env files in prod is a mistake itself, and the proposed fixes here seem to not really do much about that.

Secrets don’t belong in environment variables either. Place them in a vault and grant specific processes/identities permission to read and decrypt them. Env vars are prone to leaking and best practice moves the goal post further. Devs love to dump envs to log files, child processes inherit them, admins can very easily sniff them.

all solution inevitably evolve as "add another layer of indirection / abstraction"

there are costs associated with adding additional layer in regards to maintenance of such layer.

easiest way to bring down your entire distributed infrastructure and cause large scale outage is when your vault is down...

Re: Show HN: From dotenv to dotenvx – better config management

#137

Post by renewiltord »

sandstrom wrote: post #79

I've started using Mise for some stuff at work. Haven't digged in a lot yet, but looks really promising. https://mise.jdx.dev/ It handles task running (wipe local test db, run linting scripts, etc), environment variables and 'virtual environments', as well as replacing stuff like asdf, nvm, pyenv and rbenv. Still somewhat early days, tasks are experimental. But looks very promising and the stuff I've tried to far (ta…

I use asdf at work and mise at home. I only use it for runtime version management and it’s great!

Re: Show HN: From dotenv to dotenvx – better config management

#138

Post by atkailash »

michaelmior wrote: post #48

With leaking secrets being such a big concern, it seems wise to require that secrets be encrypted to use dotenvx. That is, it will only work with encrypted secrets. As others have commented, this doesn't eliminate the risk entirely, but I think having a tool that doesn't support unencrypted secrets at all, although a bit less convenient, is a win.

[dead]

Re: Show HN: From dotenv to dotenvx – better config management

#140

Post by kinduff »

boundlessdreamz wrote: post #64

This is similar to how Rails handles secrets - https://edgeguides.rubyonrails.org/security.html#environment... In Rails, the entire file is encrypted unlike here where only the secrets are

I really like how its implemented in Rails
Post reply on HN