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
Show HN: From dotenv to dotenvx – better config management
41–50 of 223 posts
Re: Show HN: From dotenv to dotenvx – better config management
#42Earlier quoted context omitted.
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?
Many hosting environments give you this. For example AWS gives you multiple ways of injecting secrets as env vars into your containers when they boot up (ECS + secrets manager, EKS, etc)
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.
Re: Show HN: From dotenv to dotenvx – better config management
#43So.. it just swapped ignoring `.env` for `.env.keys`?
Re: Show HN: From dotenv to dotenvx – better config management
#44Can 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?
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 permissions.
Re: Show HN: From dotenv to dotenvx – better config management
#45On my phone so can’t double test, but can’t you get this by adding “export” in front of every line in your env file and then source before running command?
I suppose if you don’t want it to stay after execution i believe you can:
> $(source .env; my command)
Re: Show HN: From dotenv to dotenvx – better config management
#46Can 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?
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.
Re: Show HN: From dotenv to dotenvx – better config management
#47I really wish 1Password would ship an environment manager for their op CLI.
Re: Show HN: From dotenv to dotenvx – better config management
#48With 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.
Re: Show HN: From dotenv to dotenvx – better config management
#49[flagged]
[deleted]
Re: Show HN: From dotenv to dotenvx – better config management
#50Earlier quoted context omitted.
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)
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 having decrypted secrets hanging out in environment variables as a middleman between your app and the cloud runtime.
Typically the application instance sessions are automatically rotated very frequently, AWS’s sessions are limited to 6 hours for example.