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

41–50 of 64 posts

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

#41

Post by ProblemFactory »

danenania wrote: post #11
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.

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…

    import envkey   # Fetches and install environment
In Python at least, that feels a bit icky. Modules can run complex code at import time, but it's rarely done.

The import order between modules is often not specified or carefully maintained, and web projects can have many main entry points. For example, a Django app might start from "wsgi.py" if run in a web server, from "manage.py" when running command-line utility scripts or tests, or from any other script file at all if a few setup lines are added.

People prefer to put all imports at the top of the file, but may want to do something right before or after envkey runs. Imports are not supposed to fail or throw exceptions, unless there is a serious code bug.

It would be nicer to have

    import envkey   # No important side-effects
    envkey.setup()  # Can be placed at the appropriate place
or similar.

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

#42

Post by bdcravens »

danmaas wrote: post #15
danenania wrote: post #7

Earlier quoted context omitted.

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.

I was able to abstract it away into a pretty simple Ruby class (for a Rails app) that writes an encrypted S3 file. That file is loaded by my containers into ENV (currently using ECS). Just a couple of method calls to update.

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

#43

Post by antoncohen »

CaveTech wrote: post #33
danenania wrote: post #31

Earlier quoted context omitted.

Good to know - as you can see, I don't have a lot of PHP experience. If anyone knows of a good way to get a PHP process's parent server pid (regardless of what server it's running on), please let me know :)

PHP has an execution model that's /really/ bad for per-process requests. Even attempting to grab the parent pid is probably not sufficient as you can have execution contexts with no parent (ex: running php from cron). On linux you can get the master process through posix-getppid ( http://php.net/manual/en/function.posix-getppid.php ) but this won't work on windows and has the same limitations as above. Have you thoug…

I think a caching daemon would be good option for PHP, but it does add a level of complexity.

Another option would be to add EnvKey support to confd (or similar project), and provide config and template files that write the env vars to Apache and Nginx configs, and reload when they change.

Though neither confd or a daemon would work for PHP sites that use a PaaS or shared hosting, which I think is a large percentage of the market for PHP.

Using one of the existing PHP caching solutions (like opcache) might be an option.

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

#46

Post by ttldr »

looks neat! would love to use something like this at work.

with regards to the S3 fail-over, how do you manage per-account access/authz?

source of fetch.go seems to indicate a single bucket is used for the fail-over: http://bit.ly/2p6ozyN

do you create per-account restricted policies and somehow have the client assume a particular IAM role or do you just have a world-readable bucket and rely on PGP for secrecy?

UPDATE: turns out that the first half of the ENVKEY (before the '-') is some sort of "env id". the S3 URL is then formed by appending the API version (v1 is valid, not sure if it's current) to the base bucket and prefix (see earlier bit.ly). for shits 'n giggles, let's try using the ENVKEY from the site's landing page ("p9WYzzHefy33gzgDdvPJ-EKdh4jgBsRBBNerK").

let's test it out with a simple, unauthenticated cURL:

  $ curl -s s3-eu-west-1.amazonaws.com/envkey-backup/envs/v1/p9WYzzHefy33gzgDdvPJ | wc -c
     15291

  $ curl s3-eu-west-1.amazonaws.com/envkey-backup/envs/v1/p9WYzzHefy33gzgDdvPJ
  ...
small sample of output for latter cmd: https://pastebin.com/igXQrk2z

so, it appears that the fail-over "feature" exposes your PGP-encrypted secrets to the world _without any authentication whatsoever_. PGP is pretty secure, and the space of potential IDs seems pretty large (20 chars^(26+26+10) ~ 4.61e80 potential IDs) so that's probably fine...

can users opt-out of the fail-over feature?

EDIT: s/security-by-obscurity//

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

#47

Post by danenania »

ttldr wrote: post #46

looks neat! would love to use something like this at work. with regards to the S3 fail-over, how do you manage per-account access/authz? source of fetch.go seems to indicate a single bucket is used for the fail-over: http://bit.ly/2p6ozyN do you create per-account restricted policies and somehow have the client assume a particular IAM role or do you just have a world-readable bucket and rely on PGP for secrecy? UPDAT…

Thanks for the feedback and for laying out your investigation :)

I'd say it's pretty unfair to call a 20 char id 'security-by-obscurity', unless you want to call almost every username/password authentication mechanism the same. The id has vastly more entropy than the average password and is far beyond brute-forcible.

Along the same lines, there are no known attacks that can break 2048 bit PGP with a sufficiently strong passphrase.

So there are two layers of security that cannot be broken by any real-world attacks. I believe that is indeed sufficient for protecting customer data.

It's likely that we'll move away from the S3 failover eventually in favor of our own replication strategy. This wouldn't really have security implications, but it does make it simpler to have a single source of truth for logging, which is coming soon.

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

#48

Post by danenania »

gingerlime wrote: post #40
pw wrote: post #36

Earlier quoted context omitted.

I don't get what the issue here is. Guess at which plan you'd need and go about your business. I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits. Even if they weren't, what's the risk here? That you'd end up owing a couple hundred extra dollars? If you're worried about that, you're probably not a customer they want. This sound like standard developer cheapness.

> I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits. I certainly hope so, but we've been bitten by surcharges before when we had a mini-DoS on our system... Besides that, there's a big element of trust here. I'm going to trust these guys with my most important secrets. I expect a trustworthy, transparent and simple solution that doesn't surprise me. Pricing is an…

Thanks for laying out your concerns. Is your feeling that any sort of usage-based tiers that go beyond per-user pricing are too complex? Or is there some way to limit usage in a reasonable way that wouldn't rub you the wrong way?

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

#49

Post by danenania »

CaveTech wrote: post #33
danenania wrote: post #31

Earlier quoted context omitted.

Good to know - as you can see, I don't have a lot of PHP experience. If anyone knows of a good way to get a PHP process's parent server pid (regardless of what server it's running on), please let me know :)

PHP has an execution model that's /really/ bad for per-process requests. Even attempting to grab the parent pid is probably not sufficient as you can have execution contexts with no parent (ex: running php from cron). On linux you can get the master process through posix-getppid ( http://php.net/manual/en/function.posix-getppid.php ) but this won't work on windows and has the same limitations as above. Have you thoug…

> Have you thought about having a linux daemon/agent that runs in the background and keeps the ENV in sync?

Yes, though I think it's also important to give developers control of when their config reloads, since surprises here can be dangerous.

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

#50

Post by danenania »

ProblemFactory wrote: post #41
danenania wrote: post #11

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…

import envkey # Fetches and install environment In Python at least, that feels a bit icky. Modules can run complex code at import time, but it's rarely done. The import order between modules is often not specified or carefully maintained, and web projects can have many main entry points. For example, a Django app might start from "wsgi.py" if run in a web server, from "manage.py" when running command-line utility scr…

Thanks for the feedback. A one-liner to import is more consistent with EnvKey's style (this is how it works in all the libraries), but perhaps it makes sense to expose the loader as a separate package so that you can have more granular control when it's necessary.
Post reply on HN