Dockerfile Best Practices

• dockerfile

  5 4,006 0.0 Dockerfile

  Dockerfile best-practices for writing production-worthy Docker images.

  

Do not hesitate to contribute then...

-> https://github.com/hexops/dockerfile/pulls

• Moby

  212 67,687 10.0 Go

  The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

  

I believe we setup containers in Docker 20.10 such that containers can bind to < 1024 by default without giving it cap_net_bind: https://github.com/moby/moby/pull/41030

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• trivy

  82 21,316 9.7 Go

  Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more

  

+1 for hadolint. There's also https://github.com/goodwithtech/dockle and https://github.com/aquasecurity/trivy if you want more security emphasis.

• caddy-docker

  30 386 5.8 Dockerfile

  Source for the official Caddy v2 Docker Image

  

I find it somewhat curious, that the article starts with listing examples where root user is used to run containers:

> Writing production-worthy Dockerfiles is, unfortunately, not as simple as you would imagine. Most Docker images in the wild fail here, and even professionals often[1] get[2] this[2] wrong[3].

And yet, in some of the linked URLs, people are presenting reasons for why that approach was used in particular, instead of the supposedly safer alternatives.

For example, https://github.com/caddyserver/caddy-docker/issues/104

> We actually originally did run as non-root by default, but simplicity we decided to drop that (see #24, and also #103 for some other related discussion).

> If your Dockerfile works for you, that's great. In most cases where users want to run as non-root, they also don't need to listen to :80/:443 in the container, so the setpcap magic isn't necessary at all.

> It's also worth noting that caddy is an official image, and as such needs to be similarly-shaped to other official images of the same type. At a quick glance, none of nginx, traefik, httpd, or haproxy support running as non-root out of the box either.

> Finally, it's worth considering why you want to run as non-root. What attack vectors are you trying to avoid? Container escape vulnerabilities are pretty much the only real risk, but anyone running a modern Docker version is immune to many of them. It's also worth considering user namespace remapping as a mitigation. In my experience the main reason for running as non-root is to pass compliance checks - not a bad reason, but it's also worth recognizing that non-compliance does not automatically equal decreased security (and vice-versa).

If larger projects, like Nginx, Traefik, Httpd and HAProxy were all creating containers like that, it makes you think about the reasoning behind it. Is it easier to just run containers as root and not worry about the permissions inside of the container? If so, wouldn't it really make more sense for the container runtime to have some sort of mechanisms in place to allow people to do what's easy within the containers while also making sure that it has no harmful impact outside of them?

Because to me it seems like people will continuously take the path of least resistance and from where i stand, it should be up to the creators of the container technologies to make sure that this path is safe by default.

• hadolint

  24 9,677 2.3 Haskell

  Dockerfile linter, validate inline bash, written in Haskell

  

Another useful resource is hadolint (https://github.com/hadolint/hadolint), which not only gives additional recommendations, but also a way to enforce this.

• docker-flask-example

  31 545 8.0 Python

  A production ready example Flask app that's using Docker and Docker Compose.

I have one here: https://github.com/nickjj/docker-flask-example/blob/ca1d4849...

The basic idea is you create a user in your Dockerfile, switch to that user with the USER instruction and now future instructions in your Dockerfile will be run as that user.

Also when COPY'ing you'll want to add --chown myuser:myuser too.

The above Dockerfile shows examples of all of that.

I'm not a fan of customizing the UID / GID because then in development with volumes you can get into trouble. Technically you could put UID / GID as build arguments but in practice I never ran into a scenario where this was needed because 99% of the time on a dev box your uid:gid will be 1000:1000 and in production chances are you are in control of provisioning your VPS so your deploy user will be 1000:1000. Also you probably won't be using volumes, but if you did it will work out of the box.

Suggest a related project