Hi HN! I’m Dane, the founder of EnvKey (https://www.envkey.com). EnvKey is an end-to-end encrypted 1Password-like service that lets dev teams manage API keys, credentials, and configuration easily and securely.
For some background, you can check out https://techcrunch.com/2018/02/27/envkey-wants-to-create-a-s... as well as a Show HN from when EnvKey first launched: https://news.ycombinator.com/item?id=15330757. 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.
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.
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 'Env Vars Locker' service that would use PGP and environment variables to solve this issue in a minimalistic way.
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 'Env Vars Locker' 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.
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.
So that’s the backstory. Now for the good stuff: how it works.
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.
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 'development' 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.
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: https://security.envkey.com
Apart from the cloud service, we'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.
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).
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.
With node, for example, it’s just:
$ npm install envkey —save
require ‘envkey’ // in main.js
Stripe.api_key = process.env.STRIPE_SECRET_KEY // this will always be in sync
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:
This allows you to use EnvKey with any language. It also pairs well with Docker.
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.
EnvKey is designed to be both simple and 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.
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'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.
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.
How would you compare EnvKey to something like HashiCorp's Vault?
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 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?
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.
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!
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!
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!
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:
small sample of output for latter cmd: https://pastebin.com/igXQrk2z
$ 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 ...
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?
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.
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
Haha, we just created this service ~3 months ago ourselfs with inheritance etc :D
How is this any different to Azure key vault? What's the benefit?
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.
The webpage says "Zero Knowledge". What's zero knowledge about envkey?
How does this compare to relying on Parameter Store if you're in AWS?