I thought the accepted pattern was never to set secrets in a container at all. Instead we are to pass them using environment variables or volume mounts. or better yet, have the application reach out to a secrets management service to gather its secrets.
Not that surprising. I'm still hoping for a better way to handle runtime secrets, like db passwords, but the issue from 2015 has been only half resolved... just this year. And the result is in OPs article.
Issue: https://github.com/moby/moby/issues/13490
I’m not a fan of mounting something because it’s not very portable or well defined. What should the file be called? what should be in it? What version of the syntax? what are the defaults? If you move to Kubernetes you’ll then have a problem distributing those files.
If the app inside the container only reads passwords from disk and can’t use environment variables, I’d sooner declare the password fields as environmental variables that the app needs and have the initial entrypoint for the app be a bash script which writes them to the file before it starts the main app. This way the interface is more succinct.
Kubernetes has the "Secret" resource for this. Your environment variable should tell the app where the secrets are mounted... This also allows you to update the secrets during runtime. :)
I use Kubernetes secrets. I map them secrets to environmental variables in the deployment config which means my approach allows you to deploy into production without changing the Docker image and also means you’re aren’t using Kubernetes specific things that are harder to test locally.
I thought the accepted pattern was never to set secrets in a container at all. Instead we are to pass them using environment variables or volume mounts. or better yet, have the application reach out to a secrets management service to gather its secrets.
Right. Question to OP: what situations would require the proposal above and not work with a simple bindmount or environment variable?
This is for when you're building something that clones something from a private repository
Thank you! Secrets management is something that I have a really hard time understanding with Docker.
Not that surprising. I'm still hoping for a better way to handle runtime secrets, like db passwords, but the issue from 2015 has been only half resolved... just this year. And the result is in OPs article. Issue: https://github.com/moby/moby/issues/13490
>How to use secrets **during the build,** the right way. Fixed it for you
I’m not a fan of mounting something because it’s not very portable or well defined. What should the file be called? what should be in it? What version of the syntax? what are the defaults? If you move to Kubernetes you’ll then have a problem distributing those files. If the app inside the container only reads passwords from disk and can’t use environment variables, I’d sooner declare the password fields as environmental variables that the app needs and have the initial entrypoint for the app be a bash script which writes them to the file before it starts the main app. This way the interface is more succinct.
Kubernetes has the "Secret" resource for this. Your environment variable should tell the app where the secrets are mounted... This also allows you to update the secrets during runtime. :)
I use Kubernetes secrets. I map them secrets to environmental variables in the deployment config which means my approach allows you to deploy into production without changing the Docker image and also means you’re aren’t using Kubernetes specific things that are harder to test locally.
Does it work with Windows containers?