Closed corneliusweig closed 4 years ago
Hi @corneliusweig
Thanks for asking the question. Your interpretation is correct - berglas exec
resolves secrets and places their values plaintext via the subprocesses environment*. It's designed specifically for legacy applications that can't easily be altered but expect configuration in an environment variable.
I thought we documented this well. Do you see areas for improvement?
Hi @sethvargo,
thanks for your speedy reply! After reading your comment, I looked more carefully and indeed I found that this is already wonderfully described.
However, that information was a bit hidden for me. Given that this can easily be used in the wrong way, what do you think about a pointer to the threat-model page at https://github.com/GoogleCloudPlatform/berglas#cli-usage item 4? It's also worth to explicitly mention that references like berglas://bucket/secret?destination=...
make berglas exec
safe again.
Also, some more information in berglas exec --help
would be great!
WDYT?
If you like, I can also try to work on this documentation.
I'm doing some dev work on berglas today and tomorrow. I'll make a point to update the docs!
You are awesome! It didn't even take a day from issue to fix :rocket:
Passing secrets as environment variables is a deprecated pattern for sensitive information (https://www.sethvargo.com/secrets-in-serverless/ or https://github.com/ahmetb/cloud-run-faq#how-to-configure-secrets-for-cloud-run-applications). However,
berglas
offers a sub-commandexec
which decrypts keys from the bucket and makes those available as environment variables to the child application: https://github.com/GoogleCloudPlatform/berglas/blob/d9641d93a6c104530e406c1578751201b7fece3a/main.go#L711-L715This seems to suffer from the same drawbacks as having secrets in plain text environment variables. Is my understanding correct about this? If so, I think it would be better if the documentation for
berglas exec
would point out that this is no water-proof approach.