|
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... |
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.