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

91–100 of 223 posts

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

#91

Post by hamasho »

I want an option to manage all env in a single file using a TOML like format like this.

  [local]
  API_KEY=local-key
  API_SECRET=local-secret
  DB=postgresql://username:password@localhost:5432/database_name
  [production]
  API_KEY=prod-key
  API_SECRET=prod-secret
  DB=postgresql://username:password@prod-db:5432/database_name
  [staging]
  API_KEY=stg-key
  API_SECRET=stg-secret
  DB=$(production.DB)
It makes it easier to update all env at once, compare, and share. It's not much help, but it helps me avoid a few annoyances.

On an unrelated note, I always find it a real headache to keep the naming convention of the environments throughout the project. It always ends up like a mixed bag:

  * Juggling production/prod, staging/stg, and develop/dev,
  * Inconsistent placement of env, e.g. prod-myproject or myproject-stg,
  * Skipping env name sometimes, e.g. myproject-bucket for dev S3 bucket but prod-myproject-bucket for prod (though it's okay to emit env name for user facing places like URL),
  * Inconsistent resource sharing between envs, e.g. same S3 bucket for local and dev but different DB, or same Kubernetes cluster with different labels for dev/stg but different cluster without a label for prod.
These inconsistencies often result from quick decisions without much thought or out of necessities, and everyone is too scared to fix them anyway. But it bothers me a lot and sometimes causes serious bugs in production.

Fix: format

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

#92

Post by tptacek »

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…

It's also problematic from a secrets management perspective, because a big part of the perceived value of encryption is being able to check secrets into git. But because the encryption is tied to long-term keys, you have to design your security processes with the assumption that those keys will eventually be exposed and need to be "revoked" (ie: the secrets re-encrypted), and the "de-revocation" of those keys is hiding in your git history.

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

#93

Post by freeone3000 »

boarnoah wrote: post #76
freeone3000 wrote: post #55

Earlier quoted context omitted.

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 Ma…

If they can snoop on env vars of a running pod, it can snoop on the process. A k8s secret could be a file in the pod or a env var in the process, but neither are a persistent file distributed to developers

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

#94

Post by [deleted] »

boarnoah wrote: post #76
freeone3000 wrote: post #55

Earlier quoted context omitted.

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 Ma…

[deleted]

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

#95

Post by ComputerGuru »

jahewson wrote: post #84
ComputerGuru wrote: post #41

We’ve been pushing for committing encrypted secrets for many years now, and have written an open source spec and implementation in multiple languages: https://github.com/neosmart/securestore-rs

I don’t get it. There’s a symmetric secrets.key that anyone could get hold of and use to overwrite secrets? No thanks. And where do I keep the key? In a secret store?

You keep the key wherever you want to keep the key, just don't commit it and don't distribute it. Put it in on a YubiKey for your devs, upload it out-of-band securely to prod.

Whether it's a symmetric key or an asymmetric key, you have the same problem. Someone overriding your secrets is definitely not high on the list of concerns, and if they're committed to git then they can never be truly overwritten.

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

#96

Post by the_duke »

We implemented the exact same method for config encryption a year ago or so, using pub/private key auth and the same `encrypted:` prefixes for encrypted config values.

This is a great tradeoff: easy way to share configuration, easy way to edit non-encrypted config values, reasonable security for the private values.

Doesn't solve key rotation of course, but for small teams this is a great solution.

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

#97

Post by ComputerGuru »

curiousdeadcat wrote: post #60
ComputerGuru wrote: post #41

We’ve been pushing for committing encrypted secrets for many years now, and have written an open source spec and implementation in multiple languages: https://github.com/neosmart/securestore-rs

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 in a .env file or similar.

EDIT:

I see you were saying "dev machine" exposes "prod secrets" but that's not the case. The protocol is designed so you would have secrets.json and secrets.prod.json, encrypted with different keys and (necessarily) managed separately but with the same tools and api. Dev machines being compromised compromises dev keys, not prod keys.

Read the last section in the README on GitHub for more on the dev/prod split.

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

#98

Post by treflop »

The only reason I use .env is because it’s dead simple and very obvious as to how it works to anyone.

If now someone has to read docs to figure out how to configure the app, I’d rather have them read docs for some other safer and more powerful configuration scheme.

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

#100

Post by ComputerGuru »

mplanchard wrote: post #70
ComputerGuru wrote: post #41

We’ve been pushing for committing encrypted secrets for many years now, and have written an open source spec and implementation in multiple languages: https://github.com/neosmart/securestore-rs

There's also sops: https://github.com/getsops/sops I've used it at two jobs now over about 5 years and have had zero issues.

Another commenter mentioned it, I'm looking at it now.

SecureStore was launched in 2017 (initial version was .NET only): https://neosmart.net/blog/securestore-a-net-secrets-manager/

Post reply on HN