Hacker News Reader

A 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.

Yeah, "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.

In 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).

There'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.

Interesting. 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?

"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.

In 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.

Just wanted to say that I'm a long time user of EnvKey and I love it. Highly recommend.

I looked at the golang code, and it's only needed for caching? You should make it clearer that the code integration is optional.

Hmm 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), 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/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.

The 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.

Ok, 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!