Does anyone here have experience / advice for building upon docker images to be run rootless? So many of the images in Docker Hub run as root by default, and its unclear to me if there's a standard UID for example to use when building them. Any resources on this would be helpful as I learn more about the topic. Thanks!
back
3 comments
That's not what rootless means at all. The image does not matter at all. What's at stake here is whether users can run a container under their own privileges, or whether the container ultimately is run by a root level user.
In either case, whether the container uses a root or user within it isn't really a factor. There's good reasons to assume user permissions within the container, but they have nothing to do with rootless containers: the idea that a regular user can launch a container is a different concept, from the permissions inside the container.
Thanks for your response. I was under the impression that the UID of a user within a container matches that which it runs under in the host machine. It sounds like that is not the case.
From what I've read, the user running a container really starts to matter when the container is given access to the filesystem (using a volume). It sounds like the user within the container still wouldn't matter in this situation, but the user running the container on the host system would have to have appropriate permissions to the volume.
In rootfull docker, that is the case, and the uid inside the container is identical to the uid outside the container. In rootless docker, the uid inside the container maps to a sub-uid outside the container. This way, it inherits the same permissions that your own uid has.
Honestly, I think the default behavior of rootfull docker is broken by design. Being able to run rootfull docker commands is equivalent to having sudo privileges, because the docker daemon has root privileges and will mount arbitrary files on your behalf.
The default behavior of rootless podman: in-container-root gets mapped to host user, anything else gets mapped to namespaced uids in a per-user specified range.
I tend to grab /etc/passwd out of the container to see what user they added for this purpose. For my own images, I use distroless (gcr.io/distroless/static-debian11:nonroot), and they use 65532: https://github.com/GoogleContainerTools/distroless/blob/main...
(I tend to write go and CGO_ENABLED=0, so I typically just pick any user and it doesn't matter. But it can matter in many common cases, so it's worth checking now to save confusion and trouble later. But, it's /etc/passwd that names the user, and filesystem internals that control file access. Typically if a container is designed for nonroot, the relevant files will be owned by the nonroot user they picked. But not always!)
I recently converted a team project over to Podman. I only had an issue with one container running rootless. Redirecting port 80 to a non-privileged port solved the issue. What are you seeing?
My eventual goal for this image is to deploy it in a Kubernetes cluster. As you can tell I'm just starting this process, but I want to be mindful of how I can keep my container secure as it runs on shared resources.
How do you handle binding to privileged ports with rootless Podman? That's what stopped me from deploying via Podman the last time I tried.
I'm using a firewalld rich rule to forward host 443 to 8443, then the proxy container has 8443:8443 mapped. Works perfectly. All on Fedora but other firewalls should be able to do the same.
I didn't. We run reverse proxies in front of our apps anyway so I just changed the port at the proxy. I wish I had a better answer for you. Maybe someone else does.
Set `sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80`