Non-privileged containers FTW!
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!
Too many containers require privileges to run
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.
Why do all the containers require privileges?
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:
- run with multiple
- bind to a port lower than 1024, or
- modify parts of the kernel
… it should not run as root.
- Docker security
- CoreOS rkt Capabilities Isolators Guide
- OpenShift Managing Security Context Constraints
Related activities and discussions
- contained.af by Jess Frazelle
- containerhardening.org by Jess Frazelle
- rootlesscontaine.rs by Aleksa Sarai
- Getting Towards Real Sandbox Containers by Jess Frazelle
- Docker and CIS Benchmark
- CIS Benchmark for Kubernetes 1.6
- The ThoughtWorks Technology Radar on container security scanning
- Privileged Docker Containers
- SO question on Privileged containers and capabilities
- Building non-ROOT containers by Sebastien Goasguen
- Understanding How UID and GID Work Inside Containers by Marc Campbell
- Running Docker Containers as non-root by Carlos Sanchez
- User Namespaces: 2017 Status Update and Additional Resources, 02/17
- Phil Estes Rooting out Root: User namespaces in Docker, 09/2016
- Michael Cherny Docker Security Features, Part 3: User Namespace, 03/2016
- Dan Walsh Are Docker containers really secure?, 07/2014
- Rami Rosen Resource management: Linux kernel Namespaces and cgroups, 05/2013
Responsible security disclosure
- Quay Security Scanner
- Docker Security Scanning
- Aqua Security Scanning and Runtime protection
- cnitch, Docker root process monitoring
Who's behind this initiative? Check out the author listing to find out.