Stop running your Docker container processes as root
- Don’t run Docker container processes as root. Santa won’t bring you any gifts if you use root.
- Use su-exec, gosu, chroot, or setpriv to step down from root into another user inside your Docker containers.
- You can use Supervisor to manage processes in Docker containers and step down from root. But unless you have a very specific use case to do so, you shouldn’t because it’s at least 50MB heavier.
Using Supervisor to manage Docker container processes (please don’t do this)
A few years ago (2015?) I used supervisor to cycle Docker container processes (such as php-fpm) without having to kill the Docker container and launch a new one. Why would any one want to do that? It simplified certain scenarios when I was developing and debugging the container.
For example, say I was launching a whole Docker Compose stack for LAMP (PHP, MySQL, Memcache, Solr, etc.), and while tweaking or optimizing a php-fpm config file the php-fpm container malfunctioned (fatal error).
I potentially would need to shut down
docker-compose down the stack. Fix the error in the php-fpm container configuration. Then bring up
docker-compose up the whole stack again. Bringing up the whole stack would be relatively fast, but still take about 1 full minute.
With supervisor, if php-fpm died for whatever reason, I would not need to restart the whole Docker Compose stack. I would login to the php-fpm container itself and restart the php-fpm process using supervisor, which would take 2–3 seconds. Find and fix the config error. Restart with supervisor, 2–3 seconds. Tweak. Restart with supervisor. You get the point.
Supervisor had it’s use for me. However, outside very specific scenarios, using Supervisor inside Docker would be counter-indicated. Docker itself natively provides the facilities to manage container processes.
Supervisor comes with it’s own space overhead.
This is my fully bespoke php-fpm Alpine image, with Supervisor:
And without Supervisor:
That’s a 56MB size difference!
Apart from the significant (huge) size savings in the Docker image, another benefit is not running supervisor as root in the Docker container. Even if supervisor can de-escalate it’s child processes user to something such as
nobody , Supervisor itself might be running as root. And that’s also counter-indicated for security reasons. And while it’s possible to run Supervisor as non-root, it requires a bit more tinkering.
Which brings me to the second thing I wanted to mention in this post:
Don’t use root in your Docker containers
Or, how to step down from root in your Docker container processes
And for our barebones Dockerfile example
Because a hipster technical post is devoid of existential meaning without one.
This shows how to:
su-execon an Alpine 3.11 Docker image;
- Step down from user
- Execute php-fpm using
FROM alpine:3.11RUN apk add --no-cache php7-fpm su-execENTRYPOINT ["su-exec", "nobody", "/usr/sbin/php-fpm7", "--nodaemonize", "--force-stderr"]
Today is Sunday, next Tuesday is Christmas. If you stop using
root Papa Noel will bring you many gifts. And if he doesn’t, your company/enterprise/hipster shop will be safer!