3 ms·

"For example, most folks that run large-scale container orchestration platforms cannot utilize their built-in secret or configuration management. These primitiv

"For example, most folks that run large-scale container orchestration platforms cannot utilize their built-in secret or configuration management. These primitives are generally not meant, designed, or built for hundreds of engineers on tens of teams and generally do not include the necessary controls to be able to sanely manage, own, and operate their applications. It is extremely common for folks to separate their secret and config. management to a system that has stronger guarantees and controls (not to mention scaling)." Fyi to anyone who is reaching (or close to reaching) this point: this is exactly the problem we're trying to solve with EnvKey[1] in a secure, robust, and scalable way. Our current product runs on the cloud (using zero-trust end-to-end encryption) and solves the problem quite well imho for companies with up to 50 or so engineers and moderately complex infrastructure. It fits easily into either containerized or non-containerized stacks. But our v2 is almost done after years of work, and I think it will now be able to handle almost any scale and workload. The launch target is August 1st. Some cool features it will offer: - Source available self-hosting with auto-scaling, HA, and strong consistency that just works. - "Config blocks" that can be used in multiple projects, allowing you to de-duplicate configuration and secrets. - Version control with simple and advanced rollback capability. - Comprehensive access logs with simple and advanced filtering and auditing capabilities. - Ability to manage local environments. - Ability to react to updates and e.g. restart servers when config values change. - A CLI that will have full parity with the UI, either for automation or those who prefer a CLI-based workflow. - An option to use our UI via an incognito web browser pointed at localhost instead of Electron (for those who hate Electron) - Faster, lighter, modernized end-to-end encryption built on NaCl (v1 uses OpenPGP, which is great, but it's time to move on). - Device based auth with optional passphrases (think SSH) and an easy, secure workflow for granting access to new devices. - Ability to authenticate and invite users via Github, Gitlab, Google, Okta, or SAML (including inviting from multiple sources within a single org). - Teams/groups and advanced group management: grant teams of users access to groups of apps, connect groups of blocks to groups of apps, etc. - Customizable everything: environments, sub-environments, and access roles can all be molded to fit your workflow. Our goal is to fully solve this crucial piece of the stack so that it "just works" with minimal time spent on integration (for new projects it can be installed and integrated in minutes). If you're interested (and/or want early access), submit your email to the form at the bottom of our site: https://www.envkey.com https://www.envkey.com -- and of course if the v1 can solve your configuration and secrets management needs as it already does for hundreds of our customers, give that a shot! Upgrading from v1 to v2 will be very quick so you won't be duplicating any work. Also, we're hiring--remote anywhere in the US. We'll put up a jobs page with more detail soon, but our stack is TypeScript (node + react), Go, and polyglot (since we need to write lots of integrations). Shoot me an email if this sounds like a system you'd be excited to work on: dane@envkey.com

sk0g 6y ago
Unfortunately I live in not-US (Aus), but I have to say, envkey looks very good! I'm actually floating this and HashiCorp Vault by management at the moment, since even with 4 devs, keeping environment variables in sync is a PAIN! If you don't mind me asking, how does the Go integration work? I initially thought it was actually some sort of alternate `os.Getenv()` that you imported, but that doesn't seem to be the case. And what would the latency be, for changes in environment variables being synced to running deployments?
- danenania 6y ago
  The go libary (along with our other language-specific libs) is a thin wrapper around envkey-fetch -- https://github.com/envkey/envkey-fetch https://github.com/envkey/envkey-fetch When a process starts, envkeygo makes a request to our config service (via envkey-fetch) to fetch the encrypted config, then decrypts the config and sets them on the environment so they can be retrieved with `os.Getenv`. Both the lookup id (for fetching the encrypted config) and the encryption passphrase for decryption are initially passed in via an ENVKEY=... environment variable--you can think of it as a single environment variable that "expands" into all the others that you need. Latency on a request is generally in the 150-300ms range from the US (our primary servers are in us-east-1). EnvKey is strongly consistent and transactional, so once you make a change to your config, it will be available immediately for any subsequent requests. For now, it's still up to you to restart servers/services yourself after a change. With the v2, this will be scriptable. We'll eventually hire outside the US too, but for now I'm trying to keep the timezone spread and administrative burden low :)

sk0g 6y ago

Unfortunately I live in not-US (Aus), but I have to say, envkey looks very good! I'm actually floating this and HashiCorp Vault by management at the moment, since even with 4 devs, keeping environment variables in sync is a PAIN! If you don't mind me asking, how does the Go integration work? I initially thought it was actually some sort of alternate `os.Getenv()` that you imported, but that doesn't seem to be the case. And what would the latency be, for changes in environment variables being synced to running deployments?

danenania 6y ago
The go libary (along with our other language-specific libs) is a thin wrapper around envkey-fetch -- https://github.com/envkey/envkey-fetch https://github.com/envkey/envkey-fetch When a process starts, envkeygo makes a request to our config service (via envkey-fetch) to fetch the encrypted config, then decrypts the config and sets them on the environment so they can be retrieved with `os.Getenv`. Both the lookup id (for fetching the encrypted config) and the encryption passphrase for decryption are initially passed in via an ENVKEY=... environment variable--you can think of it as a single environment variable that "expands" into all the others that you need. Latency on a request is generally in the 150-300ms range from the US (our primary servers are in us-east-1). EnvKey is strongly consistent and transactional, so once you make a change to your config, it will be available immediately for any subsequent requests. For now, it's still up to you to restart servers/services yourself after a change. With the v2, this will be scriptable. We'll eventually hire outside the US too, but for now I'm trying to keep the timezone spread and administrative burden low :)