Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: Generate .env files from various secret providers via checked-in config (github.com/auth70)
9 points by miunau on Jan 5, 2025 | hide | past | favorite | 6 comments
Hi! I've been frustrated with the secret sharing situation in serverside javascript land for a while; the common thing is to just toss .env files around on Slack to get someone's app working, or involves some kind of convoluted setup to get a blob from a storage and turn it into environment variables via commands I have to copy paste every time.

But everyone uses secret storage providers, e.g. shared password vaults, cloud secrets, etc., so why not leverage those as URIs in a JSON file that can be checked in to source control? I want something simple that would just generate the darn .env file with the secrets, and log me in the process if need be.

Something like..

  {
    "SECRET_ENV_VALUE": "op://application-secrets/test/test-section",
    "SECRET_ENV_VALUE2": "gcsm://projects/1234567890/secrets/SOME_KEY/versions/latest"
  }
Surprisingly I wasn't able to find anything exactly like this (most seem to want to sell me something centralised on their servers instead), so I made it. It's still quite early but I've made providers for:

- 1password (via CLI)

- AWS Secret Manager (via nodejs)

- Azure Key Vault (via nodejs)

- Bitwarden (via CLI)

- Doppler (via CLI)

- Github Secrets (via CLI)

- Google Cloud Secret Manager (via nodejs)

- Hashicorp Vault (via nodejs)

- Infisical (via CLI)

- KeePass (via CLI)

- LastPass (via CLI)

It can handle binary data from the providers that can store some, encoding it as base64 in the .env file. It tries to be nice to JSON as well.

Some (read most) of these need help testing out, so if you're interested feel free to come in to kick the tires and raise issues :)

The providers will try to log you in (or guide you through the process) if you are not, so any help making that even nicer is appreciated!



I think you might like https://dmno.dev

It has this kind of functionality (via plugins) but also does a lot more. Validation, coercion, type-safety, composability, sharing config across monorepos, leak detection…

We don’t have all of these providers as plugins yet, but they are super easy to write.

Would love to have you collaborate with us - it’s open source.


My take on why this doesn't exists to larger extent is that if you are going to go through the effort of automating, you may as well take one more step and use short-lived personal tokens instead. In a cloud, this will already be there for you, usually through OIDC. Shared secrets is a dangerous concept to begin with.


Not every service supports this, and there is still always a ton of config to manage, even if it’s not all sensitive.


Have thought about creating this exact type of thing. I will be checking this out next week, and seeing what else might be out there though. One service I see that’s missing is parameter store, but if I actually needed it I’m guessing it would be pretty easy to add unless there’s a reason for not also including it.


Parameter store should be straightforward, I wasn't actually even aware of it existing.. And yes, the more the merrier! Just make up some non-interfering URI scheme (I would probably use awspm://) that won't be reasonably used as an environment variable as is.


As for as a general reason to use it over SSM is that it’s free for like under 10k values but it’s not secure by default since it also allows non-encrypted values to be stored. AFAIK you can use basic encrypted values with it the same as SSM, but for more advanced uses there are differences.

Fun fact: SSM is also an acronym for parameter store, it used to be known as EC2 Simple Systems Manager: https://d0.awsstatic.com/whitepapers/whitepaper-ec2-ssm.pdf




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: