Stop running your Docker container processes as root

Or, how to get more gifts in Christmas

Photo by Ben White on Unsplash

TL:DR;

  1. Don’t run Docker container processes as root. Santa won’t bring you any gifts if you use root.
  2. Use su-exec, gosu, chroot, or setpriv to step down from root into another user inside your Docker containers.
  3. 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:

php-fpm with supervisor, a whole 183 MB

And without Supervisor:

php-fpm without supervisor, 127 MB

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

su-exec is a binary that allows you to run processes in Docker containers as non-root. Again, here’s why you should avoid root.

su-exec is a new-ish alternative to gosu. Both provide similar functionality, but su-exec weights only 10kb instead of 1.8MB.

And for our barebones Dockerfile example

Because a hipster technical post is devoid of existential meaning without one.

This shows how to:

  1. Install php7-fpm and su-exec on an Alpine 3.11 Docker image;
  2. Step down from user root into user nobody using su-exec , and;
  3. Execute php-fpm using su-exec :
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!

Happy Holidays !!!

Organic, fair-sourced DevOps and Full-Stack things. This is a BYOB Establishment — Bring Your Own hipster Beard.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store