[danenania]

EnvKey[1] takes a somewhat similar approach to securing credentials/config in that we effectively replace your config with a short token that can be set as an environment variable. This then 'expands' into your full configuration when it's needed.

But the crucial difference is that instead of storing sensitive data in plaintext ourselves and then sending out access tokens, we manage an OpenPGP PKI/web-of-trust for you behind the scenes so that we're only storing encrypted data, and only the token (which we never see in its entirety) can decrypt it.

End-to-end encryption is much harder to implement for these kinds of use cases than simple tokenization, but there's also the huge benefit of not needing to trust your storage layer.

With credit cards, for example, an approach like this could hypothetically remove PCI-compliance as an issue entirely because no one is actually storing the cc # in the clear. To me this is a lot more interesting than simply shifting the burden of trust. That said, anything is better than our current status quo of spraying secrets all over the place.

1 - https://www.envkey.com

[zallarak]

Huge fan on EnvKey. A perfect example of security + usability done right -- they make more convenient to do the right thing in terms of managing sensitive environment variables.

Different niche than VGS, which again, is taking a novel approach to securing sensitive information. You can tell that their founders have had real-world experience from their novel solution; using a proxy to mask and reveal sensitive information.

[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/

[SahAssar]

How would one interface with payment gateways without sending the cc #?

I get that you are not storing it in the clear, but what if I actually have to use it?

[danenania]

Yeah, at some point it needs to be decrypted, but the idea is to push it to the last possible moment, and to only allow access to whichever party actually needs to make the charge.

[SahAssar]

I don't see how that changes things at all... The payment gateway still gets the info, you still need to enter the info somehow, and in most proper e-commerce implementations these days they don't have access to the cc # anyway.

What changes except adding more work/failure-states/encryption at the one point where it does not matter?

[danenania]

I agree that for most implementations, it wouldn't make much difference. There's no point in trying to hide a cc # from Stripe, since they need it in plaintext to make the charge anyway.

But the use case of VGS as described in the article is for companies that do want to charge the cards themselves or otherwise access the cc # for whatever reason vs. outsourcing that. In this case, VGS allows you to hold a token instead of the cc #, and then you can trade your token in for the cc # (alongside some other authentication probably, like IP restrictions/anomaly detection) to make the charge.

I'm not an expert on PCI, so I don't know whether this approach truly satisfies it in itself since yes, the tokens are still sensitive. But my point is that if you're going to take this approach, and believe it does satisfy PCI, then it's strictly better if you don't have to trust VGS to store the cc # in (effectively) plaintext.

[mjallday]

Encryption is one part of PCI (data stored at rest and in transit). There's still a slew of controls that need to be satisfied when you have access to the data and there's no getting around them if you chose to take this burden on yourself.

The technology involved in persisting sensitive data on disk is a small portion of becoming compliant.

Having said that, huge fans of envkey.