On 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) I’m sure there is a fairly straightforward way to encrypt and decrypt a local file
Show HN: From dotenv to dotenvx – better config management
51–60 of 223 posts
Re: Show HN: From dotenv to dotenvx – better config management
#52The whole idea of using environment variables for configuration information is good, but ultimately flawed, and we are way past the point where this should continue to be the status quo.
Environment variables are great for configuration because:
- you can inherit them from a previous application or application(s)
- you can override them in each environment you run your app in
- you can pass them on to other applications
- they are globals that can be loaded by libraries
- they're not hardcoded in the code, so easier to change things without rebuilding, easier to reuse in different ways/environments/configurations
- the OS has primitives for them
- they're simple
- because (by default) when set in application, they are passed on to all future applications/forks/execs
- they are often dumped as part of troubleshooting and aren't considered confidential
- they can often be viewed by external processes/users
- there are restrictions on key names and values and size depending on the platform
- typical "dotenv" solution doesn't necessarily handle things like multi-line strings, has no formal specification
- no types, schemas
- configuration information passed at execution time that can change per environment
- loading or passing secret values
- development environments
- production environments
- an application library ("libconfig") that can load configuration of various types from various sources in various ways
- support for configuration types: key-value, file/blob, integer/float
- support for confidentiality (require specific function to unseal secret values; in programming languages the intent would be you can't just print a stringified version of the variable without an unseal function)
- support for schema (application defines schema, throws exception if value does not match)
- support allowing a configuration to be overloaded by different sources/hierarchies
- support passing a configuration on to other applications
- support tracing, verbose logging
- truly cross-platform and cross-language with one specification, behavior for all
- devs can create a .env file if they want
- devs load 'libconfig' into app, use it to load their configuration values during development. library can have default sources, and even set env vars or an object internally, so no code needs to be written to use it
- in production, same code causes libconfig to look at cloud-native and other sources for configuration
- when debugging, secret confidentiality is maintained, tracing communicates sources of configuration, what was loaded, from where, etcRe: Show HN: From dotenv to dotenvx – better config management
#53On 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) I’m sure there is a fairly straightforward way to encrypt and decrypt a local file
Being able to source the file is the main benefit of using a .env file, IMO. Otherwise, you can just use any format for config management.
Re: Show HN: From dotenv to dotenvx – better config management
#54I 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.
Re: Show HN: From dotenv to dotenvx – better config management
#55Earlier 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.
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.
Re: Show HN: From dotenv to dotenvx – better config management
#56Earlier 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.
During deployment, the pipeline connects to the Vault, dumps relevant secrets in a .env file that it pushes to production systems that the application then reads from.
Re: Show HN: From dotenv to dotenvx – better config management
#57Earlier quoted context omitted.
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)
Looks great, however it is much easier to work with just files, rather than key rings stored somewhere third party.
Re: Show HN: From dotenv to dotenvx – better config management
#58Earlier quoted context omitted.
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.
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 file with the decrypted secrets and just leaving it there. All the security is already kernel security.
I'm honestly not sure who dotenvx is aimed at.
- No one security conscious is going to be cool just making the cyphertext available publicly or even internally.
- Someone scrambling in-memory secrets isn't using dotenv to begin with, is using SecretsManager and the like, and probably doesn't want to change those to now go through the filesystem. You now get less auditing because all those secrets are bundled and you now only know "they accessed the decryption key."
- And someone using dotenv for secrets doesn't have a threat-model where this meaningfully improves security.
Re: Show HN: From dotenv to dotenvx – better config management
#59I 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.
Keys in the env file will ultimately be loaded as environmental variables, so it's just adding a convenience layer.
Re: Show HN: From dotenv to dotenvx – better config management
#60We’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.