
Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management - danenania
Hi HN! I’m Dane, the founder of EnvKey (<a href="https:&#x2F;&#x2F;www.envkey.com" rel="nofollow">https:&#x2F;&#x2F;www.envkey.com</a>). EnvKey is an end-to-end encrypted 1Password-like service that lets dev teams manage API keys, credentials, and configuration easily and securely.<p>For some background, you can check out <a href="https:&#x2F;&#x2F;techcrunch.com&#x2F;2018&#x2F;02&#x2F;27&#x2F;envkey-wants-to-create-a-smarter-place-to-store-a-companys-api-keys-and-credentials&#x2F;" rel="nofollow">https:&#x2F;&#x2F;techcrunch.com&#x2F;2018&#x2F;02&#x2F;27&#x2F;envkey-wants-to-create-a-s...</a> as well as a Show HN from when EnvKey first launched: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15330757" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15330757</a>. The Show HN is what got EnvKey its first batch of production users, and I probably wouldn’t have gotten into YC without it. So thanks HN! I owe a hell of a lot to this community.<p>On where the idea came from: I had the first inklings at my last job. We were in the MVP stage, so we ended up with a bunch of separate apps and services as we experimented. These were split between CloudFoundry and Heroku, and we also had an in-house test server running CI for everything on TeamCity. Keeping stuff like API keys, puma server settings, and other environment-specific config in sync everywhere was a serious headache. Bugs and failed CI builds due to missing keys were common, and our Slack quickly filled up with requests for API keys and .env files. We knew this wasn’t secure, but there didn’t seem to be any solution out there that was worth the additional complexity it would introduce.<p>One day while wrangling with TeamCity build variables, I had the thought that this could all be so much easier. Why were we painstakingly copying big blocks of config from one place to another? It was like dealing with code pre-source control. And sure, our secrets were out of git, but was spraying them all over Slack and email any better? That night, I started typing out some notes for an &#x27;Env Vars Locker&#x27; service that would use PGP and environment variables to solve this issue in a minimalistic way.<p>A bit later, I left that job to do something on my own. After a false start with a different idea, I decided that the &#x27;Env Vars Locker&#x27; had potential. I did a round of problem interviews, and people were enthusiastic. It seemed like almost every team had this issue, and it only got worse as companies grew.<p>6 months later, I had a working beta and some early users. 6 months after that, EnvKey officially launched. Now we have many customers using it happily in production. It’s growing rapidly, and lots of new features are in the pipeline.<p>So that’s the backstory. Now for the good stuff: how it works.<p>With EnvKey, configuring any development or server environment becomes as simple as setting a single environment variable(ENVKEY=F4U4jGkZuo24zKxxgJsR-4f1g2w3VpHYpYC2x). It lets you edit configuration and set access levels for all your company’s apps, environments, and teams in one place with a user-friendly, cross-platform desktop ui.<p>It keeps developers and servers in sync securely and automatically so that people don’t resort to sharing secrets over email, Slack, git, spreadsheets, etc. (a serious security risk, even with &#x27;development&#x27; secrets, since the line here is fuzzy). It also removes a whole class of config-related bugs, simplifies updates and secrets rotation, and prevents developers from interrupting each other or getting blocked when they don’t have the latest config.<p>Our servers are not trusted by any EnvKey client and cannot read or modify encrypted configuration (apart from deleting it). Public keys are verified by a web of trust during every crypto operation, and no third party gets access when you invite a new user to the system. The crypto is all vanilla OpenPGP, and all clients are fully open source. The security details are documented here: <a href="https:&#x2F;&#x2F;security.envkey.com" rel="nofollow">https:&#x2F;&#x2F;security.envkey.com</a><p>Apart from the cloud service, we&#x27;re also working on an on-prem version and a hybrid option that will allow you to store the encrypted config in your own S3 account without having it ever touch our servers.<p>For reliability, we run a high availability Kubernetes cluster on AWS, and also back up encrypted config to S3 in a separate region on every update. If any of the client libraries can’t load from the server for any reason, they’ll fail over directly to S3 (you wouldn’t even notice).<p>Unlike other tools that require heavy lifting on the ops side and complex integrations, EnvKey typically takes less than 15 minutes to setup and integrate. With a line or two of code and an ENVKEY environment variable, all your config can be accessed just like local environment variables in your code.<p>With node, for example, it’s just:<p>$ npm install envkey —save<p>require ‘envkey’  &#x2F;&#x2F; in main.js<p>Stripe.api_key = process.env.STRIPE_SECRET_KEY &#x2F;&#x2F; this will always be in sync<p>Other languages (Ruby, Python, Go) work similarly, and there’s also a bash library called envkey-source that lets you set shell environment variables with a single line:<p>eval $(envkey-source)<p>This allows you to use EnvKey with any language. It also pairs well with Docker.<p>If you already use 12-factor or a similar approach, it’s extremely easy to switch. There’s an importer for bringing in your existing config that accepts bash KEY=VAL, json, or yaml format.<p>EnvKey is designed to be both simple <i>and</i> easy, and to make a previously messy and error-prone part of your system into something you hardly ever have to think about because it just works.<p>There are a lot of interesting possibilities for the future. Why are we dealing with API keys in the first place? I think this can all be abstracted over. Imagine that when a developer leaves a company, you click once to remove them, and then all the API keys and credentials they ever had access to are all automatically rotated behind the scenes. Or imagine integrating APIs like Stripe with your whole stack in one click. That’s the kind of thing that EnvKey enables and is why I believe this approach can have a huge impact. I hope you’ll give it a try and tell me what you think! I&#x27;m super interested to hear about your ideas and experiences in this area, since HN is obviously one of the places where people are most affected by these issues.
======
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.

~~~
sametmax
So when EnvKey fails or is under attack, you lost access (or give away MITM)
to all your infra ?

~~~
danenania
This is of course a legitimate concern, but it's also one that is addressed in
EnvKey's design. Client-side encryption means that even if we are attacked, no
sensitive data will be exposed. And we have a failover to S3 so that you won't
lose access if the service goes down.

Storing config and secrets obviously requires trust, but at the same time,
many other services that developers use without a second thought actually
require a lot more trust than EnvKey does.

------
smgoller
How would you compare EnvKey to something like HashiCorp's Vault?

~~~
danenania
I've been meaning to write up a comparison with Vault for the website.
Simplicity is definitely the main differentiator. EnvKey is designed to "just
work" from a developer's perspective, and to actually save time/boost
productive instead of being an obstacle. There's no server setup or
administration, and integration is just 1-2 lines of code and a single
environment variable, vs. being a good amount of work with Vault.

In general, EnvKey is usually a 5-15 minute setup and integration process that
requires no ongoing maintenance, whereas depending on a company's level of
devops sophistication/resources, Vault is an n days - n weeks project to get
it working just right, and will usually require additional
maintenance/integration work on an ongoing basis.

Another area that I think can get overlooked with Vault is development
secrets. In my view, it is important to protect these just as well as
production secrets, since prod-level secrets can easily slip through the
cracks and end up in development environments for various reasons. Vault can
be setup to manage these, but it's not really the focus, and so you are left
to your own devices in terms of integrating it into a dev-friendly workflow.
EnvKey, on the other hand, makes distributing development config and secrets
totally seamless.

~~~
stevekemp
I think it's a little weird and biased to imply that Hashicorp's vault needs
special setup to manage development secrets.

Vault stores secrets. That's all it does. (Well it can also generate TLS
certificates, handle AWS integration and more..) Once you have a vault
instance adding a new secret takes seconds and the having an instance for
development, and a second for production is trivial.

You can also prefer a single instance with more restrictions, logging, and
similar.

* secret/$application/development/db_user * secret/$application/development/db_pass * secret/$application/development/db_host

vs

* secret/$application/production/db_user * secret/$application/production/db_pass * secret/$application/production/db_host

But the vault itself doesn't care about dev vs. prod. That's more an
infrastracture question about which hosts can talk to it, etc.

~~~
danenania
Fair enough. My point is just that getting it working smoothly with a
development workflow is another task that likely won't be trivial.

------
gingerlime
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](https://news.ycombinator.com/item?id=16477316)

~~~
danenania
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.

~~~
CaveTech
I'm in a similar boat to the OP. We're near the boundary of your pricing
between startup and traction, but the non linear jump (while being more common
these days) is an immediate turn off.

There's a pretty big difference between $240 and $1200 a year when it comes to
discretionary spending.

~~~
pw
I'd argue that if you're worried about a thousand dollars a year difference
over the course of a year, you're not a customer worth having.

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

~~~
danenania
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!

~~~
DenisM
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.

------
jeffnappi
If you're on AWS, I highly recommend taking a look at Chamber + Parameter
Store for secret management. If you're not on AWS, EnvKey looks like a
reasonable solution with ease of use. Just don't misplace the key!

[https://github.com/segmentio/chamber/blob/master/README.md](https://github.com/segmentio/chamber/blob/master/README.md)

------
pw
This looks really awesome, 'danenania. Secret management has been on my mind
lately, and this really fits a sweet spot for what I'm looking for. I know
things HashiCorp's Vault do basically the same thing, but Vault is complex
enough that sometimes I barely understand exactly what it does. Good luck!

------
Callmenorm
We've been using this service for a quite a while as a small startup, and it
changed the game for us as far as env vars go. WE LOVE IT!

~~~
ogoldberg
Same here! We're really happy with it.

------
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](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](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//

~~~
danenania
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.

~~~
ttldr
all fair points. and your product seems to be designed/documented/marketed
with the notion of keeping the username (which is part of the ENVKEY) secret,
so agreed that "security-by-obscurity" is unfair (coupled w/ massive ID
space).

your product is very well designed, seems like a tremendous customer
experience. best of luck; i hope you continue to grow

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

~~~
danenania
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?

~~~
ProblemFactory

        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.

~~~
danenania
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.

------
Selfcommit
This is a great product! Our team does something similiar with an in house
library and Google KMS.

I got a chance to talk about how it works at LISA last year:
[http://selfcommit.com](http://selfcommit.com)

------
mattipaksula
Haha, we just created this service ~3 months ago ourselfs with inheritance etc
:D

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

~~~
danenania
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 service.

\- EnvKey offers a user-friendly desktop ui for managing configuration across
apps, environments, and teams. It allows for some useful things like
inheritance and imports/exports. It's also generally better not to manage
secrets on the web if you can avoid it (mainly due to browser extensions).

\- EnvKey has much simpler access control system.

\- EnvKey makes development configuration and secrets a first-class concern,
whereas Azure/Parameter Store services tend to focus mainly on only
staging/production-level secrets.

\- EnvKey uses client-side encryption (OpenPGP) whereas Azure key vault (and
Parameter Store) use server-side keys for encryption.

~~~
danmaas
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.

~~~
bdcravens
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.

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

~~~
danenania
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!

~~~
aaronholbrook
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).

~~~
danenania
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 :)

~~~
CaveTech
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](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 thought about having a linux daemon/agent that runs in the background
and keeps the ENV in sync?

~~~
danenania
> 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.

~~~
leesalminen
I think having a daemon running on the OS that only syncs with an explicit
‘service envkey reload’ would work well.

If running php with nginx (via php-fpm), it’s still common for worker
processes to come and go rather frequently. Imo, per-request pricing just
won’t work well with php.

I would love to use your product, btw. Congratulations on launch.

-php dev

------
jiveturkey
The webpage says "Zero Knowledge". What's zero knowledge about envkey?

~~~
danenania
Configuration and secrets are encrypted client-side so that our servers can't
access this data.

------
bdcravens
How does this compare to relying on Parameter Store if you're in AWS?

~~~
danenania
Linking to my comment downthread which addresses this:
[https://news.ycombinator.com/item?id=16569534#16569940](https://news.ycombinator.com/item?id=16569534#16569940)

