Generally agreed, though I have to note that the reasoning given for needing non-root in Docker containers is flawed.

First of all, using non-root for running anything is a must-have security practice, whether you are using containers or not. It’s quite ubiquitous in vm/bare-metal environments that it doesn’t get mentioned anymore specifically but strangely it’s held ‘against’ running applications in containers.

Secondly, the reason only throws in a mention of a vulnerability but without context. That vulnerability requires the use of a specifically crafted container that exploits a system which mounts volumes from the current host. So it needs:

• that you use a third-party untrusted container as-is
• that you use a third-party base image from an untrusted source
• that you directly mount volumes from the host

If we’re discussing architecture for the cloud, none of these scenarios should be a factor. You should have practices in place to only use base images from sources performing security scans and build them with packages from trusted sources as well (just as you would in a manually setup VM).

Also, there’s userns (user namespacing) to separate user context between docker machine and host, no longer is the host root the same as container root.