4 ms·

I am curious about the third point of e2e encryption of the secrets. The problem is that the hosting provider would see plaintext secrets or that someone with a

I am curious about the third point of e2e encryption of the secrets. The problem is that the hosting provider would see plaintext secrets or that someone with access to AWS account could see them? You could also input the encrypted secrets theoretically into any service and then decrypt them in your application. Just curious on what kind of considerations do you have when choosing a hosting provider.

mcintyre1994 6y ago
It's basically the same concern as having them in source code, we want to be able to control/restrict access to them. In AWS we can do that becase they're encrypted with a KMS key and unless a user/role has permission to decrypt with that key it can't decrypt the secret. This does assume that AWS aren't lying about encrypting things, and that their employees can't access our KMS keys. We currently use Gitlab for our CI/CD pipelines, but using our own runners in our own AWS account. So if we want to deploy a staging environment from there, it's actually deploying from an AWS role that we control, we're not leaking any secrets to Gitlab or anywhere else. I'm just wondering how people get around this in Layer/any hosted CI/CD setup where you can't have your own runners inside your AWS account. Especially because they don't replace the production deploy, so ultimately those secrets are staying in AWS - perhaps in addition to wherever they need to go with Layer. FWIW I did find something about secrets in the docs: https://layerci.com/docs/layerfile-reference/secret-env#secret-env https://layerci.com/docs/layerfile-reference/secret-env#secr... - but I'm not sure how you get secrets in from that.