4 ms·
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 encry
by 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.