4 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”.

redis_mlc 5y ago
- guest and host "root" in Docker are the same, uid = 0 - there are more surfaces than process isolation to be concerned about that allow escaping a container, or affecting the guest
physicles 5y ago
This seems to mitigate the specific threat where I gain non-root shell access to the container, but there's a root process running interpreted code, which I can modify. However, if the container doesn't contain any processes running as root, there doesn't seem to be any benefit (besides defense in depth) to marking the code as read-only.
raesene9 5y ago
If you want to set the filesystem as read only in a Docker container you can do that, without needing to set-up multiple users in the container. In general that's a good piece of hardening advice, you just need to mount an empty volume for any temp files that are needed by the app. For not running as root, the main benefit (to my view) is that there have been multiple CVEs in container stacks where the issue fully or partially mitigated if the container was running as non UID-0 CVE-2021-30465 was partially mitigated, and CVE-2020-15257 had a requirement of the container running as UID-0. So whilst it's not a panacea, in general not running containers as root is a good layer of defence.

redis_mlc 5y ago

- guest and host "root" in Docker are the same, uid = 0 - there are more surfaces than process isolation to be concerned about that allow escaping a container, or affecting the guest

physicles 5y ago

This seems to mitigate the specific threat where I gain non-root shell access to the container, but there's a root process running interpreted code, which I can modify. However, if the container doesn't contain any processes running as root, there doesn't seem to be any benefit (besides defense in depth) to marking the code as read-only.

raesene9 5y ago

If you want to set the filesystem as read only in a Docker container you can do that, without needing to set-up multiple users in the container. In general that's a good piece of hardening advice, you just need to mount an empty volume for any temp files that are needed by the app. For not running as root, the main benefit (to my view) is that there have been multiple CVEs in container stacks where the issue fully or partially mitigated if the container was running as non UID-0 CVE-2021-30465 was partially mitigated, and CVE-2020-15257 had a requirement of the container running as UID-0. So whilst it's not a panacea, in general not running containers as root is a good layer of defence.