3 ms·

It’s widely accepted “best practice” to not run processes in docker containers as root but I think it does a disservice to not explain why. The top benefit in m

It’s widely accepted “best practice” to not run processes in docker containers as root but I think it does a disservice to not explain why. The top benefit in my mind is to be able to mark interpreted code (server side JS/python/ruby) as read only in case someone gains shell access in the container. It’s great to set up another user for execution, but you should also make sure to copy in code and build artifacts as read-only. I’m curious if people can name other direct benefits to a non-root user other than “I don’t trust docker/Linux process isolation”.

easton 5y ago
Because giving your app root even to the container could let it blow something up that’s important inside the container, and it means you don’t necessarily know what permissions it actually requires. Then when you get to a client site and they say “Docker isn’t on our approved software list” you won’t know what permissions it needs to install. There’s a low chance of this scenario happening, but lord knows there’s a Unix greybeard somewhere that doesn’t want Docker on his precious pets, and will like to know what permissions your app actually needs.
Spivak 5y ago
If you’re using a userns then power to you it’s all the same since you’re not really root. If not then you’re playing a dangerous game because now your container is running as root on the host system which is almost certainly not what you want. The fundamental security boundary on Linux is users and containers are not a sandboxing solution. You can use seccomp, SELinux, gvisor, or honestly virtualization to get real sandboxing and docker can use those tools to create a sandbox but Linux namespaces alone “containers” aren’t that. You can use these tools without any namespacing and vice versa. It’s not a question of “not trusting” process isolation but defense in depth. If you wouldn’t be comfortable running every process on your host system as root and put full trust into SELinux, AppArmor, and seccomp then you shouldn’t start just because you added a high-tech chroot.

easton 5y ago

Because giving your app root even to the container could let it blow something up that’s important inside the container, and it means you don’t necessarily know what permissions it actually requires. Then when you get to a client site and they say “Docker isn’t on our approved software list” you won’t know what permissions it needs to install. There’s a low chance of this scenario happening, but lord knows there’s a Unix greybeard somewhere that doesn’t want Docker on his precious pets, and will like to know what permissions your app actually needs.

Spivak 5y ago

If you’re using a userns then power to you it’s all the same since you’re not really root. If not then you’re playing a dangerous game because now your container is running as root on the host system which is almost certainly not what you want. The fundamental security boundary on Linux is users and containers are not a sandboxing solution. You can use seccomp, SELinux, gvisor, or honestly virtualization to get real sandboxing and docker can use those tools to create a sandbox but Linux namespaces alone “containers” aren’t that. You can use these tools without any namespacing and vice versa. It’s not a question of “not trusting” process isolation but defense in depth. If you wouldn’t be comfortable running every process on your host system as root and put full trust into SELinux, AppArmor, and seccomp then you shouldn’t start just because you added a high-tech chroot.