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

31–40 of 223 posts

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

#31

Post by bbor »

Etheryte wrote: post #16
jitl wrote: post #13

Secrets in env vars in production is not too secure either, ideally you’ll move to your app pulling secrets in-process from your infrastructure at boot-up or upon use. This also gives a nice advantage of not needing to rebuild the app or container or whatever to rotate a secret.

This just moves the problem to a different step. How are you going to manage access to said secrets, especially when your application lives off premises?

Yeah but it seems like the right step — deployment, not implementation. All my secrets are managed by GitLab AFAIR, but in general I feel way better integrating secrets into each service/container (I happen to use Dokku, so it’s as simple as something like `dokku add_secret APPNAME SECRET`) than having a central system.

I am far too clumsy to trust myself to push secrets in encrypted form, personally

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

#33

Post by bluelightning2k »

Etheryte wrote: post #16
jitl wrote: post #13

Secrets in env vars in production is not too secure either, ideally you’ll move to your app pulling secrets in-process from your infrastructure at boot-up or upon use. This also gives a nice advantage of not needing to rebuild the app or container or whatever to rotate a secret.

This just moves the problem to a different step. How are you going to manage access to said secrets, especially when your application lives off premises?

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)

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

#34

Post by golergka »

I don't think encryption is a good idea, and the reason is forming bad habits. Now developers have a very strong and non-ambiguous habit: never put .env files in version control (except may be for .example.env). However, with this, you'll get accustomed to commit .env in _some_ projects, so you'll easily slip and commit it in another project where the vars are not encrypted.

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

#35

Post by candiddevmike »

daralthus wrote: post #9
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.

You can commit your secrets as an encrypted vault with this. Then decrypt it with a key where needed: locally, on CI, on prod, etc. This is basically a simplified version of Hashicorp's Vault, GCP key vault etc. with some less granularity on user authentication. It solves the issues around .env.example and is perfect for gitops. You have all your secrets for all your envs ready, while you only need to set a single en…

https://rotx.dev can also be used for a local password safe, and it supports environment variables injection into various scripts or workflows.

(author of rot)

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

#36

Post by Atotalnoob »

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 be not ideal as then they can use these secrets in production or leak them

2. The secret encryption key change causes the need to re encrypt everything.

3. People don’t understand the concept.

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

#38

Post by mplanchard »

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/getsops/sops

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

#39

Post by smallerfish »

Etheryte wrote: post #16
jitl wrote: post #13

Secrets in env vars in production is not too secure either, ideally you’ll move to your app pulling secrets in-process from your infrastructure at boot-up or upon use. This also gives a nice advantage of not needing to rebuild the app or container or whatever to rotate a secret.

This just moves the problem to a different step. How are you going to manage access to said secrets, especially when your application lives off premises?

Doppler is very nice, although it gets expensive at the middle tier, which is needed to separate by role.

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

#40

Post by rrgok »

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?

Post reply on HN