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

71–80 of 223 posts

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

#71

Post by vinnymac »

jitl wrote: post #50
bluelightning2k wrote: post #33

Earlier quoted context omitted.

I've always wondered this. Seems like a password to get more passwords is potentially actually less secure (as in practice people will reuse master keys and they might actually increase the surface area, or make it a persistent threat after the keys themselves rotate)

In AWS and other clouds, you application can use an infrastructure provider API to create a secure session to access infrastructure APIs with per-application-instance credentials that are automatically rotated and can be used only by that instance. These APIs are how the cloud provider themselves provides environment variable injection features, but if your application consumes these APIs directly you can avoid havin…

Dotenvx has a cloud hub from which the keys can be pulled. I imagine an eventual feature will be for the keys to expire, and you’ll have to re-authenticate with the cloud to get new credentials, just as you would with AWS.

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

#72

Post by vinnymac »

daralthus wrote: post #4

Would be nice to be able to configure which .env file to read as an environment variable. Why? Imagine a package.json with this line: `start: dotenvx run -f .env.local -f .env -- node index.js` Instead of the -f flag, which now cannot be overriden, one could invoke it with `DOTENV=.env.staging npm run start`

You can, you just need to define the private key.

For example

DOTENV_PRIVATE_KEY_PRODUCTION

Would provide it with the information it needs to read .env.production

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

#73

Post by aforwardslash »

Spivak wrote: post #58
jitl wrote: post #42

Earlier quoted context omitted.

This is still “env vars”, easy to read from /proc/*/env too see the decrypted secrets from a different process. Versus in-process only secret fetch where you’d need to scan the memory pages of the app, which is a bit harder - especially if you keep the credentials in memory in a scrambled format so a simple scan on process memory for “secret_prefix_” doesn’t find them.

If an attacker can read other processes' envs you've pretty much lost as they're 1. Inside your process which means they can see the decrypted values. 2. Root which means they can get into your process to see the decrypted values. I'm not sure if your average dev has a threat model that assumes in memory scrambling let alone leaked env vars. After all we're talking about the standard way to do it being populating a f…

In adittion, if I'm not mistaken, child processes inherit the parent env vars, so if your application forks or use subcommands, you may be exposing the whole environment trove to 3rd party scripts, no root needed. Also, most vulnerabilities that enables execution of code will happily leak the env vars, no root access or "being inside the process" thingy (I know, code execution is technically "inside the process", but without requiring privileged levels)

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

#74

Post by cyberax »

I _detest_ this kind of encryption. It's literally worse than useless. It makes life much harder during debugging, and it eventually leads to developers just storing the decryption keys locally.

For this kind of encryption to work, you need to supply the decryption key from some outside system (e.g. via env vars, AWS SSM, etc.). And if it can supply the key, then why not just use it for other important secrets directly?

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

#75

Post by bluelightning2k »

daralthus wrote: post #54
bluelightning2k wrote: post #30

I don't really understand why this is a new project. Seems it would have been pretty simple to add these in a backwards compatible way. It would only break in cases where people's values specifically started with "encrypted:"

It was added in a backwards compatible way, but the author decided to make a breaking change with this release. The previous (IMHO superior) version was generating a .env.vault and a .env.keys from a .env file. Leaving the .env plain text and .env.vault encrypted.

Maybe the simple idea is to start a company. Nothing wrong with that. It's definitely what I would do. First envx then "envx vault"

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

#76

Post by boarnoah »

freeone3000 wrote: post #55
rrgok wrote: post #46

Earlier quoted context omitted.

Oh well, I really appreciate you taking the time to explain it. But honestly, I didn't understand a word. I recognize it is my lack of knowledge. I hope someone can do me a ELI5.

Something else pulls from the vault and exposes it as a regular env var to your process. The .env file is a workaround to get this running locally! For open source, the simplest to explain is using a k8s secret mounted to a pod — pod identity allows access to the secret via rbac, which cannot be faked. Only that pod has access to that secret. But your process, running on the pod, sees it as an env var.

That doesn't cover what the GP was talking about with

> (i.e. if someone were to gain access to a running Kubernetes container)

right? Since those would still be secrets available in the env.

I get that if someone has access to read your envvars, its a foregone conclusion already (about how compromised you are).

However IIUC, the part of the point of doing things in memory with reading secrets (like with a Secrets Manager, is to eliminate having to keep secrets around as envvars/secret files in the runtime?

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

#77

Post by nahtnam »

Atotalnoob wrote: post #36
brigadier132 wrote: post #26

Encrypting secrets and committing them seems very convenient but I'm paranoid about these sorts of things. Can anyone tell me why this would be a bad idea? One reason I can think of is that normally with secrets I actually don't keep any copies of them. I just set them in whatever secret manager my cloud environment uses and never touch them again unless I need to rotate them. Meaning there is no way to accidentally…

Using encrypted secrets provides a way better developer experience than using a vault. Typically, developers can’t change production secrets in vaults and need to follow some other protocols. Encrypted secrets mean you deploy everything along side the secrets. The developer experience is great, but the biggest issues I have faced while using Kubeseal were 1. Developers HAVE the secret in order to encrypt it. This can…

Another benefit is that debugging secret changes is a lot easier. We've had a couple of cases where someone changes the secret in a vault and that causes problems and no one can tell what changed between two deploys

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

#78

Post by solatic »

brigadier132 wrote: post #26

Encrypting secrets and committing them seems very convenient but I'm paranoid about these sorts of things. Can anyone tell me why this would be a bad idea? One reason I can think of is that normally with secrets I actually don't keep any copies of them. I just set them in whatever secret manager my cloud environment uses and never touch them again unless I need to rotate them. Meaning there is no way to accidentally…

The biggest issue with storing secrets in version control with the code is that past secrets are never relevant after they have been rotated. This makes rollbacks risky. Consider:

  1. Create secret v1
  2. Code v1
  3. Deploy
  4. Secret v2 (rotation)
  5. Code v2
  6. Deploy
  7. Oops, need to roll back to v1 (from step 2)
  8. Outage, because the secrets in step 2 are not the secrets from step 4

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

#79

Post by sandstrom »

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 (tasks) works really well.

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

#80

Post by gregwebs »

cyberax wrote: post #74

I _detest_ this kind of encryption. It's literally worse than useless. It makes life much harder during debugging, and it eventually leads to developers just storing the decryption keys locally. For this kind of encryption to work, you need to supply the decryption key from some outside system (e.g. via env vars, AWS SSM, etc.). And if it can supply the key, then why not just use it for other important secrets direct…

I use tools that read secrets out of vaults on demand using existing infrastructure for key management. For AWS there is aws-vault.
Post reply on HN