Live data from Hacker News

Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

news.ycombinator.com

11–20 of 64 posts

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#11

This whole thing was created because it's annoying for devs to set up Vault, but Vault is an Ops process, not a Dev process. Just use environment variables and let Ops take care of exporting them via a credential management system. Coding a specific credential management system into your app is a bad idea.

Thanks, you raise a good point.

To be clear, EnvKey is completely based around environment variables, so you won't need any EnvKey-specific code in your app apart from a line or two to install/import the package.

In code, config is accessed in the same way as local environment variables. For example, with python, it's just:

  $ pip install envkey

  # in main.py (the entrypoint of your app)
  import envkey

  # anywhere else in your code
  stripe.api_key = os.environ["STRIPE_SECRET_KEY"]
If you decide to switch to some other approach based on environment variables, all you need to do is remove the envkey package. Does that help to address your concern at all?

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#12

This whole thing was created because it's annoying for devs to set up Vault, but Vault is an Ops process, not a Dev process. Just use environment variables and let Ops take care of exporting them via a credential management system. Coding a specific credential management system into your app is a bad idea.

What about reboots though? You need to reboot / relaunch some services to pick up latest env vars.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#13
It’s kind of odd that you need to provision the “root” key into each client. You still have the problem of this key leaking from setup images or scripts or emails or slack or git.

I would expect the local client to generate a cert and register it with the CNC server, then wait for it to get authorized server-side.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#14

This whole thing was created because it's annoying for devs to set up Vault, but Vault is an Ops process, not a Dev process. Just use environment variables and let Ops take care of exporting them via a credential management system. Coding a specific credential management system into your app is a bad idea.

Thanks, you raise a good point. To be clear, EnvKey is completely based around environment variables, so you won't need any EnvKey-specific code in your app apart from a line or two to install/import the package. In code, config is accessed in the same way as local environment variables. For example, with python, it's just: $ pip install envkey # in main.py (the entrypoint of your app) import envkey # anywhere else i…

Doesn't really make sense. Why are you importing this package if you're getting the creds via environment? Why wouldn't you just load the creds into the environment with an external tool, and then just run your app, and never have to modify your app in the first place?

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#15
post #4

How is this any different to Azure key vault? What's the benefit?

I haven't personally used Azure key vault (or Azure in general), but as it looks comparable to AWS Parameter Store, here are a few potential benefits of EnvKey: - EnvKey is host-agnostic, so if you ever want to migrate to a different host, use an external CI tool, or even just bring up a quick script that relies on some configuration, that's trivial with EnvKey, whereas it might not be so easy with the Azure-specific…

Parameter Store is rather cumbersome and heavyweight for the kind of quick iteration you can do with EnvKey, and of course it's AWS-specific. I do use Parameter Store to "inject" the EnvKey into newly-booted EC2 instances, but then EnvKey takes over from there.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#16

Earlier quoted context omitted.

Thanks, you raise a good point. To be clear, EnvKey is completely based around environment variables, so you won't need any EnvKey-specific code in your app apart from a line or two to install/import the package. In code, config is accessed in the same way as local environment variables. For example, with python, it's just: $ pip install envkey # in main.py (the entrypoint of your app) import envkey # anywhere else i…

Doesn't really make sense. Why are you importing this package if you're getting the creds via environment? Why wouldn't you just load the creds into the environment with an external tool, and then just run your app, and never have to modify your app in the first place?

Importing the package is what sets the config on the environment.

If you'd prefer not to modify the app at all, you could also use EnvKey's bash tool, envkey-source: https://github.com/envkey/envkey-source

This lets you set the config as OS-level environment variables, and therefore doesn't require adding a library to your app. With an ENVKEY environment variable set, it works like this:

  $ eval $(envkey-source)
  $ python
  
  >> import os
  >> os.environ["SOME_API_KEY"]

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#18
post #13

It’s kind of odd that you need to provision the “root” key into each client. You still have the problem of this key leaking from setup images or scripts or emails or slack or git. I would expect the local client to generate a cert and register it with the CNC server, then wait for it to get authorized server-side.

You raise a good point. EnvKey minimizes the number of secrets that you need to deal with, but you still do have to protect ENVKEYs (the access keys that EnvKey generates).

The idea here is to create a simple 'base layer' for access that can work with any host. Environment variables fit the bill nicely because you'll almost always have some way to set one, and access to these will generally be coupled to server-level access.

That said, I'm definitely interested in adding other options for integration.

For example, I'm currently working on a way to store encrypted configuration in S3 buckets you control instead of in EnvKey's cloud. With this approach, you could define bucket policies (for both development and production-level secrets), that would restrict access by IP or by security group. That way, even if an ENVKEY leaked, it couldn't be used outside of a privileged context.

There are definitely other possibilities too. I'll look into the CNC server approach. Thanks!

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#19
It looks really interesting, and I would definitely consider it (we're in the process of re-thinking our secret management solution. It works, and it's secure, but a bit clunky). We're a small bootstrapped company with only 4 developers currently.

I have to say, though, that the pricing looks a bit intimidating. Not from the cost perspective, but just the complexity of it all. And you seem to penalize growth (there was a discussion[0] on HN that I think you triggered actually).

I really find it hard to estimate how many config requests or connected servers we might have... And the last thing I want is for things to stop working or trigger some unknown billing when we're bootstrapping new servers, or re-jigging our configs.

Per developer sounds totally reasonable to me. You're aiming to make secrets management simple. Can't your pricing mirror this?

[0] https://news.ycombinator.com/item?id=16477316

Post reply on HN