4 ms·

> Using ENV to store secrets is bad practice because Dockerfiles are usually distributed with the application, so there is no difference from hard coding secret

> Using ENV to store secrets is bad practice because Dockerfiles are usually distributed with the application, so there is no difference from hard coding secrets in code. This sounds wrong. If secrets are in the environment they are not in the Dockerfile, so they are NOT distributed with the application.

LawnGnome 6y ago
What they're referring to is more specific than environment variables in general: you can use the ENV command in a Dockerfile to bake in a secret at build time, and that's what you generally shouldn't do. Injecting environment variables at runtime, however (through docker run -e or whatever orchestration system you're using), is good.
- naranha 6y ago
  Ah yes, that makes sense. I didn't understand they were talking about the ENV command at build time. It was the heading that got me on the wrong path, I think that should be clarified further: > Do not store secrets in environment variables
  - pvtmert 6y ago
    I'm bit aganist having env-secrets inside container. Because PID 1 has that env, all processes spawned from that can read all of those. I prefer mounting them to /run/secrets via tmpfs. Which can also have selinux policy attached. This way, someone else cannot read them by spawning shell inside container
sethhochberg 6y ago
I don't think the author is talking about loading secrets from the environment - I think they're specifically talking about hardcoding secrets into the Dockerfile and using the Dockerfile ENV directive to set secrets for the processes running in the container (baking them into the image), instead of passing them at runtime, which sounds just horrifying enough that I'm sure people do it in real codebases.
innomatics 6y ago
This confused me as well. I didn't know that there was the ENV command for dockerfiles. It never occurred to me that someone would want to use that, and certainly not to put a secret in a plaintext dockerfile. Seems such an obvious tip first up that it put me off reading the rest of the article.

LawnGnome 6y ago

What they're referring to is more specific than environment variables in general: you can use the ENV command in a Dockerfile to bake in a secret at build time, and that's what you generally shouldn't do. Injecting environment variables at runtime, however (through docker run -e or whatever orchestration system you're using), is good.

naranha 6y ago
Ah yes, that makes sense. I didn't understand they were talking about the ENV command at build time. It was the heading that got me on the wrong path, I think that should be clarified further: > Do not store secrets in environment variables
- pvtmert 6y ago
  I'm bit aganist having env-secrets inside container. Because PID 1 has that env, all processes spawned from that can read all of those. I prefer mounting them to /run/secrets via tmpfs. Which can also have selinux policy attached. This way, someone else cannot read them by spawning shell inside container

sethhochberg 6y ago

I don't think the author is talking about loading secrets from the environment - I think they're specifically talking about hardcoding secrets into the Dockerfile and using the Dockerfile ENV directive to set secrets for the processes running in the container (baking them into the image), instead of passing them at runtime, which sounds just horrifying enough that I'm sure people do it in real codebases.

innomatics 6y ago

This confused me as well. I didn't know that there was the ENV command for dockerfiles. It never occurred to me that someone would want to use that, and certainly not to put a secret in a plaintext dockerfile. Seems such an obvious tip first up that it put me off reading the rest of the article.