Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 64 posts

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

#21

Post by peterwwillis »

danenania wrote: post #16
peterwwillis wrote: post #14

Earlier quoted context omitted.

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) $ pyt…

Using the bash tool is a great solution, and is way less technical debt than adding code to an app. I would have the tool execute apps directly rather than export them to bash, though both are useful.

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

#22

Post by danenania »

gingerlime wrote: post #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 w…

Thanks for the feedback. As you can see from that thread, EnvKey started out with per-developer pricing.

The main issue is that we have some customers who use EnvKey with hundreds of servers and only one or two users. This, of course, doesn't work out very well for us in terms of unit economics and pricing based on the value the service provides.

That said, the usage caps are meant to be generous and not get in the way. If you're using EnvKey in a 'normal' way and not spinning up thousands of parallel processes or something along those lines, you'll be way, way under the limits on config requests. For connected servers, it's really just a question of how many server instances you're running that use EnvKey, which is something I would think you need to plan for anyway when it comes to hosting costs.

I'm very open to adjusting these based on feedback if they are getting in the way / not matching up correctly with value. But as much as I'd prefer otherwise, I'm afraid there do need to be some sort of usage-based limits to make it work.

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

#23

Post by danenania »

peterwwillis wrote: post #21
danenania wrote: post #16

Earlier quoted context omitted.

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) $ pyt…

Using the bash tool is a great solution, and is way less technical debt than adding code to an app. I would have the tool execute apps directly rather than export them to bash, though both are useful.

Great - I'm glad that's a better fit for you :)

You can accomplish 'executing an app directly' with a sub-shell like this:

  $ (eval $(envkey-source) && run-app-command)
That way, the variables won't be exported in the parent shell.

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

#24

Post by DenisM »

danenania wrote: post #18
DenisM wrote: 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…

Now that I think of it, you don't even need a CNC server, you can make do with a public FTP site. The client will generate a cert, send it to FTP server, an on-prem app will download it from the FTP, the admin will review the fingerprint and sign the cert with his own key, then the on-prem app will encrypt all secrets with all signed certs and push them back to the FTP server. Substitute FTP for S3/etc as needed.

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

#25

Post by peterwwillis »

DenisM wrote: post #12
peterwwillis wrote: post #9

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.

No matter what you're getting a value from, if you want it to be able to change without restarting, you have to add a custom routine to do so. Adding a custom routine to get an environment variable is the same as adding a custom routine to call an API method.

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

#28

Post by danenania »

aaronholbrook wrote: post #26

Any luck in bringing support to PHP yet? I know we had chatted a while ago about that being a possibility - was hoping that was still on the radar.

Yes, it's definitely still on the radar. I have a basic version working, but ran into some complexity with Apache and PHP's request model. It doesn't make sense to run EnvKey in every PHP process (since they are per-request), so I'm thinking it needs to cache based on the Apache pid. I'm still working out the best way to accomplish this. Sorry for the delay!

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

#29

Post by cyberferret »

We've been using EnvKey since nearly the first day it was launched, and it has really made key management for our project and team easier on a massive scale.

Prior to that, we were looking at Vault or the AWS baked in key management solutions, but all of those were extremely tedious to set up and maintain. In total honesty, we migrated over to EnvKey within about 20 minutes (from over 30 secrets stored in server environment variables and .env files. Adding new secrets for new services takes a few seconds, and there is no need for us to redeploy elastic beanstalk instances when we do. EnvKey is definitely one of the 'top five' third party services that we integrated with for our development work, and we are still on the grandfathered free plan, and received no incentives for posting this, other than being a grateful customer.

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

#30

Post by aaronholbrook »

danenania wrote: post #28
aaronholbrook wrote: post #26

Any luck in bringing support to PHP yet? I know we had chatted a while ago about that being a possibility - was hoping that was still on the radar.

Yes, it's definitely still on the radar. I have a basic version working, but ran into some complexity with Apache and PHP's request model. It doesn't make sense to run EnvKey in every PHP process (since they are per-request), so I'm thinking it needs to cache based on the Apache pid. I'm still working out the best way to accomplish this. Sorry for the delay!

Ah, no worries.

I'm not sure if you're thinking it would be web server dependent, but NGINX is the bigger share of the market. (Ideally it wouldn't matter what the web server is though).

Post reply on HN