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

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

v2.envkey.com

Post reply on HN
Print view View original

21–30 of 67 posts

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

#21

Post by danenania »

KMag wrote: post #20
danenania wrote: post #11

Earlier quoted context omitted.

Good question. envkey-source catches kill signals and then sends a SIGTERM on to the process it's running. The process then has a few seconds to handle the SIGTERM and clean up before it's forcefully killed with SIGKILL (the amount of time is configurable via an argument). Does that answer your question?

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.

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

#22

Post by danenania »

itake wrote: post #18
danenania wrote: post #14

Earlier quoted context omitted.

We need to distinguish between the server where EnvKey's API is running, which contains EnvKey's back-end logic, and 'client' servers (or user devices) that are connecting to EnvKey to fetch config for a particular app/environment. (It's possible I misunderstood the distinction the parent comment was getting at.) EnvKey's API server has no access to secrets data. But you're right that a server pulling secrets via an…

> - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently. I looked at the ruby sdk code and it doesn't periodically remove them from RAM. Storing the ENVs in the `ENV` object makes me nervous, because its an easy target for supply attacks to dump the `ENV` to logs / remote servers.

You're right--another distinction is needed here. For a human user using EnvKey, the EnvKey 'core-process' will run on their computer. Both the EnvKey UI and the CLI talk to this core process to fetch/display data or make updates. This is the process that will periodically evict secrets from RAM if they aren't used.

When loading a single environment via an ENVKEY access key, you're correct that there is no RAM eviction (in many cases this could break an app, unless it was designed to handle it).

If you don't want to use ENV/environment variables, you could also output your environment to a file and then pull it into your app and parse it (you can easily export to json, yaml, dotenv, or pam format):

$ es --dot-env > .env

$ es --json > .env.json

$ es --yaml > .env.yaml

$ es --pam > /etc/environment

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

#23

Post by danenania »

NAR8789 wrote: post #16

Any plans for SOC or ISO27001 certification?

Yes, we plan to start the process soon for our Cloud service. In the meantime, our Enterprise Self-Hosted product runs in your own AWS account with no external dependencies, and is SOC/ISO27001 ready. Community Open Source could also fit the bill depending on your needs. You can find more details on our different offerings here:

https://v2.envkey.com/pricing

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

#24

Post by zmxz »

How is this tool different to Hashicorp's Vault?

Also, if I'm using "Enterprise Self Hosted", which means I am doing the hosting myself - am I not responsible for all the protection features you outlined there? If it's on my hardware, I'm doing the backups, patches, DDOS protection and so on?

I'm sorry if I sound blunt, but the pricing page looks like you tried to enlist as many buzzwords as possible to sound relevant. Auto-cluster mode sounds like PM2 cluster mode (PM2 being the supervisor tool).

There's many oddities in the pricing page, I won't list them all but I think you can see why I'm skeptic about your software. Vault does a great job dealing with secrets and is less ambiguous about what or how it does it.

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

#26

Post by itake »

danenania wrote: post #22
itake wrote: post #18

Earlier quoted context omitted.

> - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently. I looked at the ruby sdk code and it doesn't periodically remove them from RAM. Storing the ENVs in the `ENV` object makes me nervous, because its an easy target for supply attacks to dump the `ENV` to logs / remote servers.

You're right--another distinction is needed here. For a human user using EnvKey, the EnvKey 'core-process' will run on their computer. Both the EnvKey UI and the CLI talk to this core process to fetch/display data or make updates. This is the process that will periodically evict secrets from RAM if they aren't used. When loading a single environment via an ENVKEY access key, you're correct that there is no RAM evicti…

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 another process (thus limiting what access simple supply chain attacks have access to).

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

#27

Post by nicoburns »

itake wrote: post #26
danenania wrote: post #22

Earlier quoted context omitted.

You're right--another distinction is needed here. For a human user using EnvKey, the EnvKey 'core-process' will run on their computer. Both the EnvKey UI and the CLI talk to this core process to fetch/display data or make updates. This is the process that will periodically evict secrets from RAM if they aren't used. When loading a single environment via an ENVKEY access key, you're correct that there is no RAM evicti…

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?

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

#28

Post by KMag »

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

Also, after you SIGTERM/SIGKILL your child processes, you check their exit statuses, right? Otherwise your child processes also sit around as zombie processes until you exit, the zombie orphans become children of init, and init properly "reaps" the zombies by checking their exit statuses.

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

#29

Post by NAR8789 »

danenania wrote: post #23
NAR8789 wrote: post #16

Any plans for SOC or ISO27001 certification?

Yes, we plan to start the process soon for our Cloud service. In the meantime, our Enterprise Self-Hosted product runs in your own AWS account with no external dependencies, and is SOC/ISO27001 ready. Community Open Source could also fit the bill depending on your needs. You can find more details on our different offerings here: https://v2.envkey.com/pricing

Will take a look, thanks!

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

#30

Post by danenania »

zmxz wrote: post #24

How is this tool different to Hashicorp's Vault? Also, if I'm using "Enterprise Self Hosted", which means I am doing the hosting myself - am I not responsible for all the protection features you outlined there? If it's on my hardware, I'm doing the backups, patches, DDOS protection and so on? I'm sorry if I sound blunt, but the pricing page looks like you tried to enlist as many buzzwords as possible to sound relevan…

Thanks for your feedback. Enterprise Self-Hosted runs in an AWS account that you control. It uses AWS Aurora and Fargate, along with a handful of other AWS supporting services. Auto-scaling, high availability, a private network, backups, patches, and DDOS protection are all built-in.

The goal is to make running self-hosted, production-ready EnvKey as easy and hands-off as possible. All the details on setup, deployment, and management are here:

https://docs-v2.envkey.com/docs/enterprise-self-hosted

The main differences with Vault are EnvKey's client-side end-to-end encryption, which doesn't trust the host API server under any circumstances, much simpler integration, much easier setup/maintenance for self-hosting (takes about an hour for a scalable, production-ready cluster), and many developer productivity features around managing environments, avoiding duplication, handling environment updates, access control, and a lot more.

All that said, I take your points and we will try to improve our pricing page.

Post reply on HN