Live data from Hacker News

Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

v2.envkey.com

51–60 of 67 posts

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#51
post #26

Earlier quoted context omitted.

Those cmds write the variables unencrypted to disk? Looking at the ruby sdk, I don't see any decryption libraries being used. I'd imagine a more secure solution would be to give the sdk the decryption key when the variables need to be decrypted, they are only decrypted by the process in RAM. Since its ruby, and everything has access to everything in the process, it might make more sense to key management to exist in…

Since it's Ruby, wouldn't any supply chain hacks have access to the source code, and thus the decryption key?

True, but if the attack isn't targeted to the application, the attacker may naively just dump the `ENV` object instead of trying to it in the gem's memory space.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#52

Earlier quoted context omitted.

In the short term you could just tell people to use your 'eval' approach, and punt on the issue. :) Looking at your code, what's missing is a SIGCHLD handler. Basically, your code doesn't know when one of its children dies. You're making an assumption that you know how many children you currently have, based on how many you spawned; but this is misleading due to PID1 semantics re: orphaned processes. SIGCHLD lets you…

Thank you. This comment sums up why I love HN! We will improve this ASAP. Is there somewhere I can ping you once we make the changes? Would be great to be sure we haven't missed anything in your estimation. Edit: made an issue to track this: https://github.com/envkey/envkey/issues/3

Sure. I've just subscribed to the ticket.

I'm not an expert on the topic. Like you said, we're on HN: there's probably five people here who have written PID1 for an actual Unix. :) But I'm happy to take a look.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#53

Earlier quoted context omitted.

Why does client side encryption matter? explain it like I'm 5 please

If the host server is compromised, attackers still will not be able to access secrets. Vault attempts to mitigate this with its 'seal' functionality, but in practice if an attacker gains access to a running Vault server, and/or the cloud provider account it's running in, there are many ways that secrets could be exposed. EnvKey allows you to avoid trusting the host server, full stop.

If cloud account is compromised, there are far worse implications that just being ble to access Vault's secrets and no, it's not true that there are "many" ways secrects could be exposed. That's precisely what Vault protects against.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#54
post #53

Earlier quoted context omitted.

If the host server is compromised, attackers still will not be able to access secrets. Vault attempts to mitigate this with its 'seal' functionality, but in practice if an attacker gains access to a running Vault server, and/or the cloud provider account it's running in, there are many ways that secrets could be exposed. EnvKey allows you to avoid trusting the host server, full stop.

If cloud account is compromised, there are far worse implications that just being ble to access Vault's secrets and no, it's not true that there are "many" ways secrects could be exposed. That's precisely what Vault protects against.

Vault attempts to protect against host compromise scenarios, but it's a very hard problem. Ultimately, in order to do anything useful, Vault deals with plaintext values in memory, and that means that yes, there are ways for an attacker to get access.

Here's a good example: https://github.com/slingamn/vault-exfiltrate

The Vault docs include a list of 'hardening' steps for secure production usage. These are great steps to take, but each one represents a mistake that could be made. And because the Vault process is trusted with plaintext secrets, the stakes are high. Making a mistake could lead to a compromise.

With EnvKey, the host server is never sent secrets in plaintext. For defense in depth, we also follow best practices for hardening our networks. But I think we've seen with Okta and other incidents that despite best intentions, best efforts, and strong engineering, trusting the host server whatsoever just isn't good enough anymore.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#55
post #20

Earlier quoted context omitted.

If your child processes spawn grandchild processes and then exit or otherwise die, and envkey-source is running as PID 1, then envkey-source will become the parent of those orphaned grandchild processes. When those orphans exit, envkey-source must check those process's exit status. Until then, those process IDs can't be reused, and the processes stick around as zombie processes. In other words, PID 1 is special, beca…

Thanks, I'll have to look into this more deeply. Currently cleanup is being left to the watched process, but it sounds like more rigorous monitoring of grandchild processes is needed.

For some examples of what to do, see

https://github.com/Yelp/dumb-init

https://github.com/krallin/tini

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#56

Earlier quoted context omitted.

Why does client side encryption matter? explain it like I'm 5 please

If the host server is compromised, attackers still will not be able to access secrets. Vault attempts to mitigate this with its 'seal' functionality, but in practice if an attacker gains access to a running Vault server, and/or the cloud provider account it's running in, there are many ways that secrets could be exposed. EnvKey allows you to avoid trusting the host server, full stop.

In this regard envkey is much like 1password or lastpass, the server never knows the contents of your vault.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#58

Earlier quoted context omitted.

I've met the Doppler founders and greatly respect them (even played some poker with them!). Doppler has great design and UX. That said, I'd say the key difference is that EnvKey places much more emphasis on security and privacy. Doppler is cloud-hosted and doesn't use end-to-end encryption, so it requires that you trust them to keep your data safe and not make any mistakes in their data security, network security, wh…

Co-founder/CTO of Doppler here. I'd agree that Doppler currently focuses very heavily on UX. We aim to fit into developer workflows, regardless of where devs run their code. This includes local development (macOS/Windows/Linux), CI/CD, Kubernetes, Vercel, and just about anywhere else. We've found that security tools that are difficult to use end up being worked around by developers, which ultimately decreases an org'…

I wonder why is it difficult to add an extra password on top of the access key. What I mean is you can have another password or hash (separate to normal auth pass) which is only used to encrypt at browser and decrypt at the time of usage(through env load packages or your custom doppler command. This extra password is never sent or stored at doppler server.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#60
I'm a happy EnvKey customer since the end of 2018. After me and my team tried different solutions in the past (back in 2017 and 2018) to manage secrets on our infrastructure (we have a mix of kubernetes and VM's in diffeerent places) we read about EnvKey here on HN and we decided to give it a try. We fell in love with the product from minute 1. We use it for production and staging environments and it has worked like a charm from the start.

V1 is straightforward to setup, straighforward to use, and the best of it: it just works. Adapting all services to use it is very easy, even if you don't want to change the application itself, as long as uses environment variables, you can just launch it through envkey-source and it just works. I must say it has worked flawlessly for me for the last 3.5 years. So I'm very happy with it. In case anybody is considering to use it, I would encourage to give it a try. Honestly.

I cannot speak too much about the latest version (v2) yet, because we have not "migrated", although for what I've read so far, it looks even better than V1 as a product.

I think the reload functionality might be quite handy when running some services (although not a clue how well it will work in practice), and I always missed the option to have an API or command line to update secrets without opening the GUI. I mean, the GUI is great, but sometimes if you have to update a bunch of stuff (like SSL certificates) on a bunch of services, command line is just more convenient because you can script it or do it all at once.

I also appreciate the fact that it is moving to open-source because that means there is no "lock-in" to the company anymore, and even if the company fails, I can still use the product.

So, having said this, let me add a little of criticism on V2.

I don't like the fact that, as a customer, we have to migrate from V1 to V2. I mean, maybe I've got it wrong, but as far as I understood V1 is going end of life by the end of the year and if I want to continue using the product I have to migrate to V2. I guess that there is probably no way for EnvKey to migrate secrets from V1 to V2 transparently, so clients need to do this one-time migration, but that means changing all EnvKeys on all our services because the current ones will stop working, plus updating all libraries in all our services to V2. It is not like a difficult change to make, but we manage a lot of services and this looks like some sort of "bureaucracy" to go through to change to a major version.

I'm sure this is not a problem for new customers of EnvKey, but as 3.5 year-customer it is something unpleasant to do. Again, it might probably not take us long to do it, but I foresee spending some time with it, and I don't want to focus on a 3rdparty tool maintenance, I want to focus on my customer's problems. Some sort of backwards compatibility, or automatic migration would have been awesome. Dane, if you tell me the same "EnvKeys" will keep working on both V1 and V2, then I'll be amazed and happy, but so far I haven't read any communication about that, so I'm just guessing it won't.

The other thing that changed is pricing. As I mentioned before, I like the fact that it is now open source. Here is the thing, though, I'll be more than happy to continue paying for the service, because hosting it myself means having to spend time on it, which again, I don't want. I want to focus on the problems of my customers, so here comes the thing for me, now there are 4 tiers: OpenSource, Community Cloud (Free), Business Cloud (499/mo) and Enterprise Self-Hosted (1499/mo).

I've been paying 20/mo for the last 3.5 years, which was a nice price for our small team (even cheap). Going from paying 20/mo to 499/mo will make me think on self-hosting or looking for another solution. It exceeds the money I would like to spend on this. I miss something in the middle. I would happily continue paying 20/mo or even 50/mo, I would even evaluate paying something like 79/mo or even 99/mo at most but something higher than that does not justify keep using the service for me and my team (given our current size).

I'm not sure if I'm on the "free" tier anymore, because the pricing page mentions "user devices" and I don't know if that means user accounts (like the accounts using the EnvKey GUI App?) or what it exactly means... and same for "Server EnvKeys" does that mean each of the EnvKey projects or is that the amount of servers/services instances I have pulling secrets from EnvKey? Not clear to me. Finally, regarding the "Cloud Usage" credits, in the end, if I understood correctly this basically means X amount of storage and Y amount of bandwidth and Z amount of connections with different limitations. The problem I see with this is the same problem I see when I try to figure out pricing in AWS. I have no clue where I stand on those things, so I have no clue on whether that is too much or too little before using it. I can guess, but what does "active connections mean"? I guess this refers to the fact that the new tool with auto-reloading will use some sort of sockets/permanent connection, and for each of my service instances I would consume 1... but it makes it complex. This is probably a way for EnvKey to keep the costs controlled, but as a customer is makes things difficult to reason about in terms of pricing. Secrets, at least in my organization, are very small strings or very small files, so 100MB of storage data or 1GB of bandwidth (even if it was per month) seems like a lot, but probably you have different clients consuming different things, but the number of requests / number of connections...

Dane, if you are reading this, you certainly have better context than I do, but I believe that given a "reasonable" usage, EnvKey would be more appealing if it just charged on number of "seats" or maybe even on number of "projects" and be generous in everything else (cloud credits), even though I agree you should have some limitations. Personally, I think lowering the benefits on the "Free" tier and creating something in the middle between that one and the "Business Cloud (499/mo)" would make it more appealing to more teams. At least it would be more appealing to me/my team. Right now, without knowing if I'm going to be on the V2 free tier or on the Business tier (which is not worth the money for me), I would certainly explore the option of self-hosting and/or moving out to another service. Migrating to free to discover I'm on the business tier and then having to move away requires some extra effort that I'm not willing to do. In both cases your company is losing us as a paid client (even if a small one so far).

Again, as I initially said, it is an amazing product and I really like it, but I'm not sure my team will be using the paid version anymore due to the new pricing.

I hope my comment helps somehow to either bring new customers and/or for the pricing of EnvKey to evolve.

(edited it to clarify a couple of sentences)

Post reply on HN