[Artemis2]

Looks cool! I can very much appreciate progress in this space. I haven’t been able to find this info by skimming the website: while I understand that the user ultimately holds the keys that can decrypt the secret, how do you prevent this key from becoming the weakest link? Assuming the worst, users could just store their key where they used to store their secrets before EnvKey (like app environment)?

Something I appreciate very much about running in the cloud is being able to use the control plane’s APIs to authenticate requesters (e.g. Kubernetes API + Service Accounts or AWS IAM + Instance Roles). Does EnvKey have anything in the way of that?

Regarding PCI compliance: if card data is encrypted, the scope of compliance simply moves over to the keys :-)

[danenania]

Thanks! Yeah, the key still needs to be protected--the benefit is that you minimize the number of secrets you need to deal with, but it unfortunately isn't possible to avoid managing some kind of secret entirely. That said, using a token instead of storing the secrets directly also allows for additional access control (say by IP range), quicker/more effective revocation and rotation, and makes it trivial to keep developers and infrastructure in sync (this was always a major problem in my experience with approaches like 12 factor).

We're definitely interested in other authentication approaches that leverage pre-existing cloud credentials/roles, but for now are sticking with the simplicity/universality of an environment variable, since just about every platform supports them, and access is generally coupled to server-level access.

Integrating with Kubernetes in particular is very straightforward--you just set an ENVKEY secret, expose it as an environment variable to your pods, install envkey-source[1] in your containers, and then run a single line `eval $(envkey-source)` to inject your config. Or to make it even simpler, one of our users has figured out an approach that avoids the need to install envkey-source/eval it in your container at all[2].

"Regarding PCI compliance: if card data is encrypted, the scope of compliance simply moves over to the keys :-)"

True enough! This could also be said about e.g. your Stripe secret key, though you're still less screwed by having this exposed than losing the cc numbers directly.

1 - https://github.com/envkey/envkey-source

2 - https://medium.com/@dmaas/add-envkey-to-a-docker-app-in-kube...

[Artemis2]

Thanks for the detailed reply! There is indeed a lot to do with authentication/authorization (and things like audit logging…). I’ll look more at EnvKey later to understand the cryptography better.

Stripe/other gateways do abstract most of PCI DSS from you, and will not return card data via API calls, so that somewhat sidesteps the compliance issue.

[danenania]

I look forward to hearing your thoughts--feel free to email me directly: dane [at] envkey.com

All the crypto/security details are here btw: https://security.envkey.com/