Dockerfile Best Practices
I find it somewhat curious, that the article starts with listing examples where root user is used to run containers (amongst other issues):<p>&gt; 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].<p>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.<p>For example, <a href="https:&#x2F;&#x2F;github.com&#x2F;caddyserver&#x2F;caddy-docker&#x2F;issues&#x2F;104" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;caddyserver&#x2F;caddy-docker&#x2F;issues&#x2F;104</a><p>&gt; 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).<p>&gt; If your Dockerfile works for you, that&#x27;s great. In most cases where users want to run as non-root, they also don&#x27;t need to listen to :80&#x2F;:443 in the container, so the setpcap magic isn&#x27;t necessary at all.<p>&gt; It&#x27;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.<p>&gt; Finally, it&#x27;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&#x27;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&#x27;s also worth recognizing that non-compliance does not automatically equal decreased security (and vice-versa).<p>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&#x27;t it really make more sense for the container runtime to have some sort of mechanisms in place to allow people to do what&#x27;s easy within the containers while also making sure that it has no harmful impact outside of them?<p>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.