3 ms·

> Do not store secrets in environment variables Yes, definitely don't put secrets in the Dockerfile itself. I'm curious if there are reasons not to use a .env

> Do not store secrets in environment variables Yes, definitely don't put secrets in the Dockerfile itself. I'm curious if there are reasons not to use a .env file though? > Only use trusted base images This is a good sentiment, but docker hub also has plenty of images that are built directly from a github repo. You can inspect the Dockerfile and (as long as you trust Docker) trust that it was built as written. In this case I recommend pinning to a specific container SHA (image_name@sha256:...) in case the source repo gets compromised. For official images, you can pin to a tag IMO. > Do not use ‘latest’ tag for base image Regardless of the security concerns, pinning to latest will probably bite you when there's a major version bump (or even maybe a minor one). Imagine you built a container on ubuntu:latest when latest was 20.04 and some new employee gets hit with 22.04. That's a bad surprise. > Avoid curl bashing Evergreen fight here, but I agree with the author that you should at least validate checksums on external files before executing or using them. > Do not upgrade your system packages This is where the throne of lies about Docker idempotency crumbles. You have to apt-get update because Debian/Ubuntu repositories remove old versions when there are security fixes (not 100% sure on this, feel free to correct me). So if the ubuntu:20.04 image is released and there's a security update in openssh-client, running "apt-get install openssh-client" without "apt-get update" will fail. So we all run "apt-get update" and pretend that the containers we build are time-invariant. They're not, and in fact we occasionally get security updates snuck in there. Luckily Debian and Ubuntu do a good job not breaking things and no one complains. But if you build a container on Tuesday it's not guaranteed to be the same as on Wednesday and there's nothing you can do about that with a Debian distro. But it's actually fine in practice so we pretend not to notice. The point about not running "apt-get upgrade" is kind of moot - you're going to effectively be upgrading whatever you "apt-get install", so it's probably worth taking the same trade on the built-in packages. Importantly, there's no security risk - just a configuration one. > Do not use ADD if possible Same as above - you should be checksumming external dependencies or self-hosting them. > Do not root > Do not sudo I haven't thought deeply about these. I'd prefer to trust the container system isolation rather than playing with users and permissions. I don't understand this risk well enough to have a well-formed opinion.

kelnos 6y ago
> Yes, definitely don't put secrets in the Dockerfile itself. I'm curious if there are reasons not to use a .env file though? Because often that .env file will get checked into source control (sometimes intentionally, sometimes accidentally), and then you have secrets in your git history that you need to rotate. In general the best thing to do is store your secrets in a place/service specifically designed for secrets, and either fetch them directly into the container in your entrypoint, or pull them into a location that you mount as a volume in the container. > I'd prefer to trust the container system isolation rather than playing with users and permissions. Don't. Containers don't give you full isolation. The 'root' user inside the container is the same 'root' user as outside, and container escapes may be possible. A good defense-in-depth strategy suggests that you should run things using the least privileges possible, and that doesn't change just because something is running in a container.
gbellinoz 6y ago
> you should at least validate checksums on external files before executing or using them. I would do that by getting the checksum off the website, and hardcoding it into my Dockerfile, right? At that point I've pegged to a version, and I might as well just keep the binary local and COPY it in. Is that right? And am I accidentally reviving the 'evergreen fight'? :)
PowerBar 6y ago
>> Do not store secrets in environment variables > Yes, definitely don't put secrets in the Dockerfile itself. I'm curious if there are reasons not to use a .env file though? Environment variables are a terrible place to store secrets, regardless of whether you're using docker. Environment variable values get dumped all over the place. /proc/*/environ, docker inspect, /var/log/..., core dumps, error messages, info pages (phpinfo), etc. Also, unlike file handles and secrets services (hashicorp vault, etc), every child process inherits all of its parents' environment variables, greatly increasing the attack surface.

kelnos 6y ago

> Yes, definitely don't put secrets in the Dockerfile itself. I'm curious if there are reasons not to use a .env file though? Because often that .env file will get checked into source control (sometimes intentionally, sometimes accidentally), and then you have secrets in your git history that you need to rotate. In general the best thing to do is store your secrets in a place/service specifically designed for secrets, and either fetch them directly into the container in your entrypoint, or pull them into a location that you mount as a volume in the container. > I'd prefer to trust the container system isolation rather than playing with users and permissions. Don't. Containers don't give you full isolation. The 'root' user inside the container is the same 'root' user as outside, and container escapes may be possible. A good defense-in-depth strategy suggests that you should run things using the least privileges possible, and that doesn't change just because something is running in a container.

gbellinoz 6y ago

> you should at least validate checksums on external files before executing or using them. I would do that by getting the checksum off the website, and hardcoding it into my Dockerfile, right? At that point I've pegged to a version, and I might as well just keep the binary local and COPY it in. Is that right? And am I accidentally reviving the 'evergreen fight'? :)

PowerBar 6y ago

>> Do not store secrets in environment variables > Yes, definitely don't put secrets in the Dockerfile itself. I'm curious if there are reasons not to use a .env file though? Environment variables are a terrible place to store secrets, regardless of whether you're using docker. Environment variable values get dumped all over the place. /proc/*/environ, docker inspect, /var/log/..., core dumps, error messages, info pages (phpinfo), etc. Also, unlike file handles and secrets services (hashicorp vault, etc), every child process inherits all of its parents' environment variables, greatly increasing the attack surface.