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

111–120 of 223 posts

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

#111

Post by nunez »

rrgok wrote: post #40

Can a kind soul point me some documentation on how to put .env in a vault correctly? Possibly open-source solutions? If the vault is password protected, aren't you just adding one more indirection and nothing more? How is that helpful, since now I have to write the vault password in clear-text somewhere such that my application can read the env file from the vault?

Add your actual dotenv to .gitignore. Use bfg to make sure that any traces of your dotenv aren't in your commit history. Use detect-secrets client-side commit hook to confirm this and also monitor for secrets leakage. Use sops to encrypt your dotenv into some other file that is tracked by git. Sops can integrate with secrets management solutions (Vault, AWS KMS, etc.). Done.

This is mildly complicated, but the alternative is storing config in a configuration server somewhere, which comes with its own can of worms.

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

#112

Post by hadlock »

mplanchard wrote: post #38

Seems pretty similar to sops[0], but without the encrypted-by-default feature that makes sops feel significantly safer for secret management. Sops also integrates easily with AWS and other existing key management solutions, so that you can use your existing IAM controls on keys. I mentioned in another comment, but I've been using it over five years at two jobs and have found it to be great. [0]: https://github.com/ge…

I've been using sops in production since at least 2017, plus it has excellent compatibility with containerized infra tools like helm and other infra tools like terraform (both technically using plugins, but helm secrets and the carlpetts terraform plugin have been around for ages and are widely used.

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

#113

Post by TZubiri »

Importing a set of library and dependencies to handle reading a plain text file poses more risks than just leaving the file unencrypted.

You don't need to encrypt your keys, with what keys are you going to do so? Will you encrypt those?

if someone is in your server you are pwned anyways.

It's ok if you identify yourself as a cybersecurity dude and hold a cybersecurity role and you need to justify your livelihood.

But do it in a way where you don't bother people. It's ok if you bother devs, but then you go on and bother users with 4FA, 5 rule passwords, systems that can't answer subpoenas because you have encrypted your sense of self.

When you are improving security at the expense of every other variable, that's annoying, but when you keep "improving security" at the expense even of security, is the point where people will start ignoring and hiding shit from you

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

#114

Post by poopsmithe »

nimishk wrote: post #90

I don't think this is the best approach. I am building https://phase.dev which lets you import secrets (.env), encrypt secrets (end-to-end encrypted with keys you control), sync them to other services/platforms (think AWS, GitHub, Kubernetes), and inject them into applications at runtime (e.g., phase run node index.js). Source: https://github.com/phasehq/console

What do you mean it's not the best approach? That's a little light on the details.

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

#115

Post by postalrat »

rrgok wrote: post #46
c0brac0bra wrote: post #44

Earlier quoted context omitted.

A lot of modern cloud deployments read from a secret management system or vault at deployment time, and the secrets are made accessible to the application through various indirect methods so they cannot be accessed later on (i.e. if someone were to gain access to a running Kubernetes container). At no point does the application have access to the vault itself, and access to read the vault is guarded by IAM role permi…

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.

A script fetches values from a database then sticks them in a file. This script runs before the your application starts so the file will be there waiting.

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

#116

Post by cyberax »

slt2021 wrote: post #87
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 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 without knowing decryption key - I think it is important for collaboration

So basically, you want developers (who don't have access to prod) to add random properties that your peers can't see during the code review? Ok...

Sorry, there's just no way the encrypted secrets in git are a good idea for general-purpose software.

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

#119

Post by NegativeK »

TZubiri wrote: post #113

Importing a set of library and dependencies to handle reading a plain text file poses more risks than just leaving the file unencrypted. You don't need to encrypt your keys, with what keys are you going to do so? Will you encrypt those? if someone is in your server you are pwned anyways. It's ok if you identify yourself as a cybersecurity dude and hold a cybersecurity role and you need to justify your livelihood. But…

> if someone is in your server you are pwned anyways.

This is false and also a symptom of an all-or-nothing approach to cybersecurity, which isn't feasible in the real world.

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

#120

Post by daralthus »

nunez wrote: post #108

dotenvx encryption goes a long way towards solving THE BIGGEST problem with dotenv; using multiple tools to ensure that secrets are protected. I wonder if dotenvx ensures that .env is in .gitignore and yells loudly if it is not. I encrypt my dotenvs with gpg, but that's hella esoteric and everyone shouldn't be forced to do that.

and .dockerignore
Post reply on HN