[HN Gopher] Show HN: EnvKey 2.0 - End-To-End Encrypted Environme...
___________________________________________________________________
Show HN: EnvKey 2.0 - End-To-End Encrypted Environments (now open
source)
Hey HN, I'm so happy to finally show you all this release after
years of hard work. I posted the first version of EnvKey to HN back
in 2017 (https://news.ycombinator.com/item?id=15330757), then went
through YC in W18 (https://news.ycombinator.com/item?id=16569534).
EnvKey is an end-to-end encrypted configuration and secrets
manager. It protects your organization's API keys, encryption keys,
credentials, and other secrets, and makes it easy to run servers,
scripts, tests, and everything else with the latest config. It also
helps you avoid duplication in your configuration, react to
environment updates in real-time, resolve conflicts smoothly, and a
lot more. You get an intuitive, spreadsheet-like UI for managing
environments, along with a developer-friendly CLI that does almost
anything the UI can. Running any program in any language with the
latest environment variables is as simple as:
envkey-source -- any-shell-command You can use the `es` alias
to type less: es -- any-shell-command You can
automatically reload a process whenever there's a change using the
-w flag: es -w -- ./start-server To avoid
downtime on reloads, add the --rolling flag to reload gradually
across all connected processes: es -w --rolling --
./start-server You can run custom logic when there's a change
instead of restarting: es -r ./reload-env.sh --
./start-server Or run something _only_ when there 's a
change: es -r ./env-change-hook.sh You can
pass command line arguments from EnvKey variables (just wrap your
command in single quotes): es 'curl
https://$HOST_URL' You can export your environment to the
current shell: eval "$(es)" Or auto-load the
latest environment in any EnvKey-enabled directory (like direnv):
echo $'\n\neval "$(es --hook bash)"\n' >> ~/.bash_profile
EnvKey is now open source under the MIT license and can be self-
hosted. Our Cloud and Enterprise Self-Hosted products also include
commercially licensed server-side extensions for auto-scaling,
highly available infrastructure and advanced user management. Cloud
is free for up to 20 user devices and 40 server keys. EnvKey's
client-side end-to-end encryption is built with the NaCl crypto
library. Whether you use EnvKey Cloud or host EnvKey yourself, no
configuration or secrets are ever sent to the host running EnvKey
in plaintext. Public keys are verified by a web of trust.
Invitations are verified out-of-band. Secrets are never accessed
through a web browser. More details on security and encryption can
be found here: https://docs-v2.envkey.com/docs/security Let me
know what you think! Thanks!
Author : danenania
Score : 154 points
Date : 2022-03-30 14:42 UTC (8 hours ago)
(HTM) web link (v2.envkey.com)
(TXT) w3m dump (v2.envkey.com)
| stuaxo wrote:
| Are there any local equivalents to this, where I can store
| project environment variables in something like libsecret ?
| nicoburns wrote:
| You can get programatic access to keypass databases. Not sure
| if there's out of the box support though.
| NAR8789 wrote:
| Any plans for SOC or ISO27001 certification?
| danenania wrote:
| 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
| NAR8789 wrote:
| Will take a look, thanks!
| itake wrote:
| All of the links to the language sdks are broken:
|
| https://docs-v2.envkey.com/docs/language-sdks
| danenania wrote:
| Oops, just fixed those. Thanks!
| weinzierl wrote:
| Is it a replacement for ansible-vault too? What are the
| advantages of a solution involving a server?
| danenania wrote:
| For many platforms and tools (like Ansible) that offer some
| form of secrets management, instead of being a complete
| replacement, EnvKey piggy-backs on whatever is the standard
| secrets management approach, then adds a lot of functionality
| and security on top.
|
| That's because EnvKey doesn't (and can't) completely eliminate
| the secrets you have to manage, but it does minimize them to a
| single secret (the ENVKEY) for each environment.
|
| So now instead of setting a bunch of variables in ansible-
| vault, in Kubernetes secrets, in AWS secrets manager, etc. etc.
| for every environment that you run, you can just set a single
| ENVKEY in each of those tools, and then access/update/manage
| everything in a single place with all the productivity features
| and additional security that EnvKey offers.
| itake wrote:
| I have a few friends that run their own crypto nodes b/c they
| don't trust cloud providers (and their employees) to have access
| to their private keys (which may control millions of dollars).
|
| Would this tool minimize the risk of an employee snapshots the
| disk and RAM of their machine?
| danenania wrote:
| Yes, EnvKey uses client-side end-to-end encryption and never
| sends secrets to the host server in plaintext (whether it's
| self-hosted or you use EnvKey Cloud). So there would be no way
| for a cloud provider employee (or an EnvKey employee) to get
| access from the server side. Even the names of your variables
| are encrypted and not accessible except on the client.
| koolba wrote:
| Except for a cold boot style attack right?
|
| https://en.m.wikipedia.org/wiki/Cold_boot_attack
|
| I'm assuming the client side code isn't keeping the secrets
| in some kind of TPM right? ie anyone with root access to the
| server or the ability to dump the memory could pull them out.
| itake wrote:
| +1, ideally, it should only decrypt (and fetch?) the when
| it needs to use the key. So 99% of the time, the key isn't
| sitting decrypted in memory.
|
| Having to trigger a network call each time the key needs to
| be used (like to sign a transaction) isn't great though
| :-/.
| danenania wrote:
| 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 ENVKEY
| access key would still have to expose those secrets in RAM
| to the process that needs them. We don't claim to protect
| user devices or connected servers from endpoint compromise.
|
| We do offer some features to help mitigate this though:
|
| - You can limit access to an ENVKEY to specific IPs or CIDR
| ranges.
|
| - On a user device, secrets are periodically removed from
| RAM if they haven't been accessed recently.
|
| - On a user device, only encrypted data is stored on disk,
| and the OS keychain is used on Mac and Windows.
|
| - If an ENVKEY's access it cut off, envkey-source can
| immediately kill the process, making the secrets harder to
| access from RAM.
|
| - Audit logs can help you track exactly what was exposed
| and when in the event of an incident.
|
| - Access to secrets is 'pushed' as far down the stack as
| possible... so your secrets at least wouldn't be accessible
| in some cloud provider database--they would need to get
| access to the running process itself or the machine's RAM.
| itake wrote:
| > - 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.
| danenania wrote:
| 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
| itake wrote:
| 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).
| danenania wrote:
| Yes, those commands write the variables to a file, though
| you could also make a system call instead from within
| your app if you didn't want them in a file _or_
| environment variables.
|
| The language SDKs (including ruby) wrap the envkey-source
| binary, which is where all the decryption and
| verification logic lives:
|
| https://docs-v2.envkey.com/docs/envkey-source
|
| There is an -m/--mem-cache flag that you can pass to
| envkey-source that makes it work just as you're
| describing. It keeps the variables in RAM and listens for
| updates, keeping them all up-to-date.
| nicoburns wrote:
| Since it's Ruby, wouldn't any supply chain hacks have
| access to the source code, and thus the decryption key?
| itake wrote:
| 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.
| yowmamasita wrote:
| Eyeing Business Cloud: How do you recommend to store the server
| key?
| danenania wrote:
| It depends on the platform you're using, but basically wherever
| you would store your secrets currently (API keys, database
| credentials, etc.) is where you should store your server
| ENVKEY.
| zmxz wrote:
| 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.
| danenania wrote:
| 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.
| 998wwwww wrote:
| Why does client side encryption matter? explain it like I'm 5
| please
| danenania wrote:
| 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.
| zmxz wrote:
| 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.
| danenania wrote:
| 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.
| tener wrote:
| How do you handle a situation where the attacker gains access to
| decrypted set of secrets and steals them? Can you prevent this
| scenario in any way, or does single hacked admin results in a
| complete compromise with no way to recover?
| danenania wrote:
| If an attacker gains access to your app's process where the
| secrets are in RAM, there's not much protection we can offer,
| since ultimately the variables need to live in plaintext
| _somewhere_ in order to be used. But recovering is a lot easier
| /faster since you can track down exactly what was exposed with
| audit logs and rotate compromised credentials in one place
| instead of needing to track them down across many
| devices/servers.
|
| For a human user, there are multiple layers of security:
| email/SSO authentication, a per-device encryption key (stored
| in the OS credential store on Mac/Windows), and, optionally: a
| passphrase that locks the per-device encryption key and a
| lockout that clears RAM and locks EnvKey on the device after a
| specified time period until the user inputs their passphrase.
| EnvKey organization owners can require that
| passphrases/lockouts be set for all org members.
| mattste wrote:
| How does this compare to Doppler[1]?
|
| Is there a way to handle the configuration in Terraform?
|
| [1] https://www.doppler.com/
| danenania wrote:
| 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, who they
| hire, what sub-processors they trust, etc. In my (very biased)
| opinion, that is not sufficient protection for the most
| sensitive data.
|
| Doppler also uses a web interface, which is great for
| convenience and UX, but leaves you vulnerable to compromised
| browser plugins, XSS, etc. I don't believe browsers are
| sufficiently secure currently for secrets management (if this
| changes, we'll add a web interface to EnvKey ASAP!).
|
| There are real costs in terms of UX to end-to-end encryption.
| EnvKey tries to be as user-friendly as possible, but doesn't
| compromise on security or privacy. Doppler's design, as I
| understand it, leans more toward the other side of this
| tradeoff.
|
| On Terraform--yes, it's easy to use EnvKey with Terraform. The
| general pattern for integrating EnvKey with any tool or
| platform is to set your ENVKEYs as secrets in whatever way the
| platform handles them, then expose each ENVKEY as an
| environment variable to your VMs, containers, or whatever else
| you're running. We'll write up a Terraform-specific guide soon
| to make it as easy as possible.
| ocdtrekkie wrote:
| > I don't believe browsers are sufficiently secure currently
| for secrets management
|
| This is a super rare view, but one I truly appreciate. The
| risk of compromised browser plugins especially is vastly
| understated and underappreciated by... way too many
| "security" "experts".
| ryukafalz wrote:
| I don't believe just about any platform we have now is
| really sufficiently secure for secrets management. Just as
| a compromised browser plugin can do a lot of damage, so too
| can a compromised desktop application (including its
| dependencies). The industry as a whole is not in a great
| place when it comes to protecting the integrity of our
| machines, especially developer workstations.
|
| (And yes I know you probably know this better than most as
| a Sandstorm dev :)
| tompic823 wrote:
| 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's security posture (see HashiCorp Vault). This does come
| with some tradeoffs- specifically that you must trust Doppler
| with your secrets, given our tokenization model[0].
|
| We do recognize that the current security tradeoffs of
| Doppler aren't going to satisfy everyone. For Enterprises, we
| offer Enterprise Key Management (EKM), which allows orgs to
| encrypt their secrets using a cloud KMS. Of course, this
| still doesn't satisfy every concern. And so, for customers
| requiring additional security guarantees, stay tuned!
|
| [0] https://docs.doppler.com/docs/security-fact-sheet
| gmfawcett wrote:
| Interesting! You show a lot of examples where the server is
| created as a child of your EnvKey process. That kind of suggests
| you might encounter EnvKey being the PID 1 in a containerized
| application. Does EnvKey have a good "PID 1 discipline" -- in
| particular, reaping zombie processes?
| danenania wrote:
| 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?
| KMag wrote:
| 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, because it may have child
| processes that it never created, and needs to be aware and
| handle them properly. Otherwise, you can end up leaking
| zombie processes.
|
| It sounds like envkey-source isn't aware that it may adopt
| orphaned child processes. Killing them isn't the main issue.
| Checking their exit statuses is the main issue.
| danenania wrote:
| 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.
| KMag wrote:
| 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.
| danenania wrote:
| The process management code lives here: https://github.co
| m/envkey/envkey/blob/main/public/sdks/envke...
|
| Basically, on unix systems, the command you pass in to
| envkey-source is run via:
|
| exec.Command("sh", "-c", c)
|
| (c is the command you passed as a string.)
|
| Stdout/stderr is piped through, and .Wait() is called on
| the command. If envkey-source is in watch mode, it will
| send a SIGTERM when the environment is updated, then re-
| run the process once the initial process has died. I can
| verify that, for example, if a server listening on ports
| is restarted in this way, the process will die and the
| ports will be cleared before the new process is started
| (this has been well-tested).
|
| Do you see a problem with this approach? We will
| prioritize making all this bulletproof.
| gmfawcett wrote:
| 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 know that a child process has died. For
| each SIGCHLD received, your program should (must!) call
| 'waitpid' (or one of its related functions) to wait on
| the dead child process. You don't need to waitpid
| _inside_ the signal handler; you just need to make sure
| that the counts of signals and waitpid calls eventually
| match up.
|
| This is in a different language, but here's a nicely
| writen article about implementing PID1 in Rust:
|
| https://www.fpcomplete.com/rust/pid1/
|
| Someone in Go-land must have written a similar module.
| Your solution might be an 'import' away.
| danenania wrote:
| 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
| gmfawcett wrote:
| 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.
| sciurus wrote:
| For some examples of what to do, see
|
| https://github.com/Yelp/dumb-init
|
| https://github.com/krallin/tini
| triumphantomato wrote:
| this seems like an awesome project! would like to learn more, but
| is it just me or is the link to the security overview broken?
| danenania wrote:
| Sorry about that! Just fixed it.
| plasma wrote:
| Looks interesting, is it a replacement for BitWarden too, or more
| focused on app environments (to set ENV vars)?
| danenania wrote:
| Yeah it's completely focused on app environments, so it's not a
| replacement for a password manager. That said, there's nothing
| stopping you from storing passwords in an EnvKey app and
| treating it as a very simple password manager. One benefit is
| that it would be very easy to manage your passwords
| programmatically in various ways if you had a need for that.
| [deleted]
| kafkaIncarnate wrote:
| Initially, I was pretty thoroughly perplexed by what this
| actually did since all I did was click the original link and
| didn't even see this post text. I figured it out through mostly
| the 2017 link above. I have a pretty good idea now and see its
| value.
|
| That being said, when looking at your actual website initially
| with no context, I couldn't really figure out what it did. My
| first instinct was to hit the "Docs" button.
|
| The "Don't README" header and the just download my code and run
| it and figure out how it works later mantra with regard to an
| end-to-end encryption software (or software in general) was very
| off-putting to me. I actually wasn't very interested in figuring
| out what your software did at that point, as it just was flashing
| red-flag in my head. Was it malware? Was it really end-to-end
| encrypted?
|
| Just a suggestion, you might want to reword some of that front
| landing page of the Docs page. I understand your wanting to
| convey that it "just works", but you might want to convey a bit
| better somehow what exactly what is just working in the first
| place, and do so in a way that isn't screaming "don't try to
| figure out how it's working". Maybe also advertise a bit more
| clearly that it's open source.
|
| The whole "unless you really want to" is a little weird, too.
| Every end-to-end encryption software you use you should
| understand fully what encryption is being used, especially when
| targeting developers handling core secrets for major
| organizations or what have you.
| danenania wrote:
| Thanks for your feedback! I'm sorry that the intro in the docs
| rubbed you the wrong way. I wanted to make sure people realize
| that it's not a complicated tool that requires a lot of setup
| or research to start using, and I guess to have a little fun
| too, but perhaps the tone is not quite right. I'll try to
| improve this.
|
| Edit: what do you think now that I've removed the (probably
| misguided) playful language in the headings?
| https://docs-v2.envkey.com/docs Better?
| kafkaIncarnate wrote:
| Yeah that's a lot better. Don't get me wrong, I love
| playfulness, especially in documentation. It's just that
| before you even really know what a product is or does it
| seemed like it was worded like "don't even try to figure out
| what we are doing here and execute untrusted code" or
| something, haha.
|
| I totally understood what you were trying to do, I just think
| if I interpreted it that way at first, others might as well.
| I at least had your other stuff to go off of to eventually
| get me to figure it out, whereas people encountering your
| page on the internet wouldn't. Was just trying to help :)
| danenania wrote:
| Thanks! You're absolutely right that if you had that
| impression, others likely would as well, and there's not
| much to gain from it--the same information can be conveyed
| in a more fitting tone. Thanks again, I really appreciate
| it!
___________________________________________________________________
(page generated 2022-03-30 23:00 UTC)