Did you know that running containers with user
root is not only a bad
practice, but really is a security risk? You might not care when launching
a single container on your laptop, but in the context of container
orchestrators such as Kubernetes, this is a real problem.
This site tries to explain the issue, collects data and reference material
and ultimately provides you with tooling to change the status quo.
We can do it, if we all work together!
A huge percentage of container images expect to be able to run as root at least briefly before dropping privileges. This leads to tons of software running with way more privileges required than are actually needed to get the job done.
Almost all software can run fine without requiring any privileges. Daemons like web service, HTTP, and databases, can easily be configured to run with only user privileges. Eliminating the need for a process to run with any Linux capacities, leads to a huge increase in security. Think of this as the security level of a multi-user system.
There is a ton of software that needs to be root,
just to bind to a port lower than 1024. After it binds to a port, it usually
changes to a different user to drop privileges, but this means it needs
CAP_GID just to become less privileged. If we just
stop binding to ports lower than 1024, we eliminate the need for these
A lot of work goes into attempting to keep containers from attacking each other. Most of these are around reducing the attack surface of the kernel and minimizing the power of root. If we just rework the way we run software, we decrease the attack surface of the system enormously.
The main reason we end up with these containers requiring privileges
is that we are using software packaging like
deb which have
built-in assumptions that you have to be root to install the software.
As we move into containers, we need to stop making these assumptions.
So unless your application needs to:
… it should not run as root.
Who’s behind this initiative? Check out the author listing to find out.