4 ms·
EnvKey (https://www.envkey.com/ https://www.envkey.com/) is another OSS alternative to Vault with a bit more focus on security (disclaimer: I'm the founder). W
by danenania 3y ago
EnvKey (https://www.envkey.com/ https://www.envkey.com/) is another OSS alternative to Vault with a bit more focus on security (disclaimer: I'm the founder).
We have a comparison with Vault here: https://www.envkey.com/compare/hashicorp-vault/ https://www.envkey.com/compare/hashicorp-vault/
We'll probably write up a comparison with Infisical soon as well but I'd say the main thing is that our end-to-end encryption has no opt-outs (as Infisical does for many of its integrations), and we use native apps and a CLI rather than offering a web UI. End-to-end encryption in a web browser offers minimal security benefit for reasons discussed in this thread: https://news.ycombinator.com/item?id=21838795 https://news.ycombinator.com/item?id=21838795 (the discussion is from 2019 and the original NCCGroup link from 2011 is now dead, but all the same issues still apply).
Also, I'm not sure if this has been addressed yet, but it has previously been noted that Infisical was completely lacking in automated tests. EnvKey has an extensive test suite ( core tests here: https://github.com/envkey/envkey/tree/main/public/app/tests https://github.com/envkey/envkey/tree/main/public/app/tests and tests for all our sdks are included in each: https://github.com/envkey/envkey/tree/main/public/sdks https://github.com/envkey/envkey/tree/main/public/sdks).
- vmatsiiako 3y agoIn my opinion, "having no opt-outs" is not a benefit. It's by definition having less functionality. Infisical offers native SDKs, API, and CLI too + many other features (such as native integrations, webhooks, dashboard, etc).
- danenania 3y agoThere's an inherent tradeoff for sure. In my opinion, I wouldn't say that any added functionality a secrets management service can offer is worth trusting all that service's servers, all its backend dependencies, all its employees and contractors, all its third party sub-processors, etc. with plaintext secrets. I'd also note that we are able to offer all the features you list without requiring users to opt-out of end-to-end encryption.
- vmatsiiako 3y agoInteresting. We work with some of the largest companies out there, and none of them had an issue with this. Curious how you are able to create a native integration with, let's say, Vercel without requiring users to opt-out of end-to-end encryption?
- danenania 3y ago"We work with some of the largest companies out there, and none of them had an issue with this." I imagine they'll regret this if you have a security incident. "Curious how you are able to create a native integration with, let's say, Vercel without requiring users to opt-out of end-to-end encryption?" We don't have a native integration with Vercel (you didn't list that in your comment, which is what I was referring to). We don't really have a need for one since all that's required to integrate EnvKey with Vercel is setting a single environment variable. That said, if we did decide to build an official Vercel integration, we wouldn't require removing end-to-end encryption to use it.
- nine_k 3y agoIn the security domain, you often want fewer features, because every feature is another thing to audit, and another chance to introduce a vulnerability. But, of course, too few features can be just impractical.
- ogoldberg 3y agoJust wanted to say that I'm a long time user of EnvKey and I love it. Highly recommend.
- 3np 3y agoA major use-case for Vault is dynamic generation of secrets, like rotating roles in a Postgres DB or acting as CA (issuing/revoking certs) in a PKI infra. Some, like the former, needs to hold secrets for and communicate with external services. How easy is this to achieve using EnvKey? Only allusion I see on the comparison page is "Easy Integration: Vault=Poor, EnvKey=Strong" but I have a feeling something else was in mind there.
- danenania 3y agoYeah, "easy integration" is more speaking to how you get secrets from Vault/EnvKey through to an app. Dynamic secrets generation isn't built in to EnvKey, but we do offer a CLI that makes it straightforward to generate or rotate credentials/roles as part of your deployment. Rather than baking in this kind of thing, we are more taking a 'give you simple building blocks so you can do anything' approach to automations. For your postgres example, it would look something like this: # Set variables for an EnvKey environment that includes postgres admin creds in shell eval $(envkey-source) # Use the admin credentials from EnvKey to rotate credentials for app role in Postgres. # You could also create new roles, grant privileges, etc., as needed. NEW_PASSWORD=$(openssl rand -base64 32) psql -h $DB_HOST -U $DB_ADMIN_USER -d $DATABASE_NAME -c "ALTER ROLE $ROLE_NAME WITH PASSWORD '$NEW_PASSWORD';" # Update the credentials in EnvKey for your app. envkey set app-name production DB_PASSWORD=$NEW_PASSWORD --commit --json Meanwhile, if you prefix your app start command like this: envkey-source --watch -- ./run-my-app.sh Your app process will then be automatically restarted after the `envkey set` command with the latest postgres password in its environment. If you're running multiple instances, you could also use rolling restarts to avoid downtime. envkey-source --watch --rolling -- ./run-my-app.sh So it's a bit more work compared to Vault for the postgres use-case, but on the other hand, with EnvKey you get a lot of flexibility to setup these kinds of automations for any service or tool. For acting as a CA, we have some ideas on how to accomplish this that I think would be both simpler and more secure than Vault's approach, but we haven't gotten to it yet.
- irq-1 3y agoI looked at the golang code, and it's only needed for caching? You should make it clearer that the code integration is optional.
- danenania 3y agoHmm thank you for the feedback, but I'm not sure if I follow you. Which golang code are you referring to? We have two different Go libraries. One is envkey-source (https://docs-v2.envkey.com/docs/envkey-source https://docs-v2.envkey.com/docs/envkey-source), which contains core client-side decryption and verification logic. It can be used standalone from the shell like this: # some-command runs with EnvKey vars in its environment $ envkey-source -- ./some-command Or like this: # EnvKey vars are set in current shell $ eval $(envkey-source) $ echo $SOME_ENVKEY_VAR And second, envkey-source is also wrapped by our language-specific SDKs, including one for Go: https://github.com/envkey/envkey/tree/main/public/sdks/languages-and-frameworks/go/envkeygo https://github.com/envkey/envkey/tree/main/public/sdks/langu... It allows you to integrate with a Go project like this: // main.go import ( "os" _ "github.com/envkey/envkeygo/v2" ) // assuming you have GITHUB_TOKEN set in EnvKey token := os.Getenv("GITHUB_TOKEN") // this will stay in sync We're planning to do a docs-improvement pass soon so I'm very interested in how we could clear up any confusing aspects of how the different pieces fit together.
- irq-1 3y agoThe second project; it only does caching of the keys. It's a big advantage to use your software without any SDK or client code. You should make it clear that it's optional.
- danenania 3y agoOk, understood. The purpose is not so much caching as setting the vars in the environment so they can be accessed in a standardized way that is compatible with dotenv, 12 factor apps, etc. But yes, you could also say they’re being cached. We do try to mention in the docs for each SDK that envkey-source can be used from the shell instead, but I’m sure we can make it clearer. Thanks again!