Show HN: SecretEnv – Run any process with secrets from all your backends(github.com)
github.com
Show HN: SecretEnv – Run any process with secrets from all your backends
https://github.com/TechAlchemistX/secretenv
10 comments
The current support for backends include
AWS SSM Parameter Store / AWS Secrets Manager / GCP Secrets Manager / Azure Key Vault / Hashicorp Vault / OpenBao / Cyberark Conjur / 1Password / Doppler / Infisical / Keeper / Cloudflare Workers KV / macOS Keychain / Local File
AWS SSM Parameter Store / AWS Secrets Manager / GCP Secrets Manager / Azure Key Vault / Hashicorp Vault / OpenBao / Cyberark Conjur / 1Password / Doppler / Infisical / Keeper / Cloudflare Workers KV / macOS Keychain / Local File
or... mise and fnox
I had evaluated fnox. However you have a dependency of encryption/decryption.
So imagine the use case where you need to roll out a password change to 10 repos or offboard an engineer from the team.
In either case, the touch point now becomes 10 repos which need to be co-ordinated against.
Now imagine doing this at scale, you need to migrate password stores entirely. Not that it happens often, however I have been at start-ups where we moved from one cloud provider to another because we gained better discounts on contracts. The password store migration then would be an effort vs just updating 1 line in registry and it resolves.
Similarly user offboarding is handled by IAM permission as well, as soon as the user access is revoked the secret resolution is gone.
Thank you for bringing up fnox and mise. This was something I had evaluated and even written about in the security threat model. :)
https://github.com/TechAlchemistX/secretenv/blob/main/docs/s...
So imagine the use case where you need to roll out a password change to 10 repos or offboard an engineer from the team.
In either case, the touch point now becomes 10 repos which need to be co-ordinated against.
Now imagine doing this at scale, you need to migrate password stores entirely. Not that it happens often, however I have been at start-ups where we moved from one cloud provider to another because we gained better discounts on contracts. The password store migration then would be an effort vs just updating 1 line in registry and it resolves.
Similarly user offboarding is handled by IAM permission as well, as soon as the user access is revoked the secret resolution is gone.
Thank you for bringing up fnox and mise. This was something I had evaluated and even written about in the security threat model. :)
https://github.com/TechAlchemistX/secretenv/blob/main/docs/s...
I am the maintainer of fnox. This is only true if you use the encryption providers. If you don't, nothing is encrypted obviously.
Your doc also doesn't seem to take into account my preferred way of using it with KMS that solves a lot of the problems mentioned.
Your doc also doesn't seem to take into account my preferred way of using it with KMS that solves a lot of the problems mentioned.
Check out https://varlock.dev - it uses functions and a plugin system to pull from different backends. But also allows composing values together in whatever way you like, has built in validation, extra protection for secrets, and a ton more.
Cool, I checked it out and must say varlock's solid, but it's solving different problem.
Varlock makes .env files smarter (validation, types, editor autocomplete, Next.js/Vite hooks).
SecretEnv gets rid of the .env files entirely. Your project lists what it needs by nickname, the actual secrets live in whatever backends your team already uses. Change backend? One line and every repo picks it up.
Both work with any language.
They could actually compose together, varlock can call secretenv to pull from the backends and validate on the top. :)
Varlock makes .env files smarter (validation, types, editor autocomplete, Next.js/Vite hooks).
SecretEnv gets rid of the .env files entirely. Your project lists what it needs by nickname, the actual secrets live in whatever backends your team already uses. Change backend? One line and every repo picks it up.
Both work with any language.
They could actually compose together, varlock can call secretenv to pull from the backends and validate on the top. :)
We piggyback on .env files with a new DSL rather than introducing a new file.
Using plugins that register new functions, you can fetch from many different backends (15 and growing). The main difference if I understand correctly is that the wiring of vars to where those things live does live in committed code, but is totally declarative and safe. It's also incredibly flexible since functions can be written to make things idiomatic for that backend. Keeping that within git makes sense to us, as you ideally want deployments to be immutable.
The other benefit is this gives you a way to manage both sensitive and non-sensitive config - with a single source of truth for validation, types, docs.
Using plugins that register new functions, you can fetch from many different backends (15 and growing). The main difference if I understand correctly is that the wiring of vars to where those things live does live in committed code, but is totally declarative and safe. It's also incredibly flexible since functions can be written to make things idiomatic for that backend. Keeping that within git makes sense to us, as you ideally want deployments to be immutable.
The other benefit is this gives you a way to manage both sensitive and non-sensitive config - with a single source of truth for validation, types, docs.
Thanks for pointing out varlock. Let me go check it out.
I built SecretEnv to help solve one common thing that I have seen at every org, that I have worked at.
We always had more than one password/credential manager. Service tokens maybe in Vault, AWS SSM etc and some team specific service account or temp account credentials being store in another password store such as 1Password or Keeper, there was never one single credential store.
This is where SecretEnv comes in play, it runs any command with secrets injected as env vars, sourced from whatever combination of backend your team already uses.
I am sure there are other tools as well that do a similar thing, which is run a command and inject secret. However SecretEnv does one thing differently.
The key idea is separating two items which are most of the time combined. Think of SecretEnv's resolution structure like an Address Book.
- Your repo gets a secretenv.toml file which has labels in there as values against ENV Vars. These can be literally anything. DB_URL, STRIPE_KEY whatever.
- You have a registry that lives in your backend that you/your company uses. This registry holds the actual paths so the credentials.
- You have a config file on your machine called config.toml that secretenv uses to grab the aliases from secretenv.toml and resolve against registry that lives in your backend.
So imagine if you are a Platform Engineer and need to migrate password stores to different backend.
You can now migrate secrets from AWS to Vault or change the naming conventions in one central place (registry) without devs having to touch their code or update config file.
What this means is if the credential is used by 10, 15 or even 20 repos. All you need to do is update the alias in the registry and all repos pick up the changes.
No need to open PR's, involve dev teams.
The whole idea was abstracting and decoupling the dependency.
The tool currently supports 14 backends already which covers most of the ground.
Would love your feedback and if there is any backends or workflow that this does not cover.
https://github.com/TechAlchemistX/secretenv