How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
Rootless helps, but less now that it used to (pre-2026). There have been a lot of local privilege escalation vulnerabilities in the Linux kernel (dirtyfrag, fragnesia, CIFSwitch et al) and several of those can be repurposed as container breakouts.
As a result, if you're looking for good security isolation, I'd say a (Micro)VM is a better option. The other route is hardening down your container runtime with seccomp/AppArmor/SELinux but that can be a tricky game.
Personally I still think this is not enough, and we really need full generalized (not AI-only) microvm support built into docker/podman, like yesterday.
Currently it's difficult to even get a hold of a properly configured minimal kernel (or time-consuming to try to build one) and all the right command-line incantations to even start a one-off microvm using say, qemu, with all the proper storage/networking/etc. bits one needs for production environments. Plus you need to keep that kernel updated very regularly.
I know there's projects like smolvm that try to make this simpler, but I've had some major problems with those solutions as well, and I just feel like the big boys need to step up and support this directly by now.
The '--userns=auto' argument is a useful isolation method in both rootless and rootful Podman containers. This allows rootful Podman to orchestrate privileged capabilities while running the container processes in an unprivileged namespace.
I've been doing this for a while now and it is by far much easier to work with and just as safe if configured properly. I think people just cargo cult thier way into wanting rootless containers for their long running services with no real look into if it's actually needed.
Rootless containers have their place, actual userspace workloads. Things like dev containers or normal users running containers but if one is creating users to run system level services then they are just adding extra steps imo.
Ran into this at our last shop, three services on one box, someone convinced everyone rootless was "safer" so we spent two days fighting UID mapping for volume permissions. Same argument, container escape still means you own that user's stuff. If it ain't multi-tenant, rootful with seccomp and read-only fs got us further for way less pain.
Small nit: --userns=auto doesn't really let rootful Podman "orchestrate privileged capabilities" into an unprivileged namespace, it just allocates a unique UID/GID range per container so they don't share overlapping subuids. Still a great flag for reducing blast radius though, IIRC it was designed mainly to stop container-to-container ID collisions.
I'd still rather use docker. I don't mind that the daemon runs as root because there are some things that you need root for anyways! Like binding to privileged ports or setting up networks (use `internal: true` and the daemon will automatically set up iptables rules that limit traffic).
I deploy docker compose files with ansible so everything comes with built in security defaults like rootless, dropped caps, no new privileges, etc. I wish more containers supported running read only (its usually pretty easy to add, just overlooked) and distroless (common for go apps, less so otherwise).
There was a pretty good comment on reddit a while back with a list of hardenings for compose files [1]
Rootless is definitely the way to go. You can forward ports manually on the host if you really need to use privileged ports. I generally expose my containers through a reverse proxy, running bare metal on the host, and that completely bypasses the privileged port issue.
That privileged port thing is not true anymore for Docker created containers, since it lowers that limit and unprivileged containers can listen on any port.
docker run -ti --rm --user 1000:1000 --privileged=false alpine:latest
~ $ cat /proc/sys/net/ipv4/ip_unprivileged_port_start
0
~ $ id
uid=1000 gid=1000 groups=1000
~ $ nc -lvp 80
listening on [::]:80 ...
Also the iptable rules Docker creates is for routing traffic to container with destination NAT, to actually limit traffic you have to do it yourself by inserting rules in DOCKER_USER chain.
The .container units get the job done, but if you want to manage a stack of containers and are familiar with Kubernetes, or just like YAML, I recommend using the .kube units instead.[1]
Rootless containers have privilege escalation risks of their own. The problem is the unprivileged_userns_clone sysctl, which rootless containers rely on, has historically been a big source of local privilege escalations. The most recent attack I'm aware of is CIFSwitch.
Has anyone actually measured how often unprivileged_userns_clone bugs get exploited in the wild versus just theorized? Rootless still shrinks the attack surface for everything else. Feels like trading one known knob for a pile of unknown ones baked into privileged daemons.
Funny timing! I just finished migrating my NAS containers all to be rootless last weekend.
"Migrating" because secrets management was a bit of a pain. I ended up with pretty close to the same design as this article though. (I put an extra layer of complexity in mine, we'll see if I regret it)
Along with the other folks in this thread, I don't think we can stop at rootless in 2026. But I'm optimistic that dropping in libkrun as the runtime will be an easy next step, given its integration with podman (--runtime=krun).
If the author tackles that next, I'd be interested in reading about it
Interesting... yeah if you think of Docker as an easy way to setup environments that's one thing but if you are intending airtight isolation so processes inside Docker can't "escape" most conventional use cases / discourse haven't really focused on that I think
Rootless containers just revive what chroot jails and Solaris zones tried in the 90s/2000s — good enough for isolation, terrible if kernel has a hole. Difference now: attack surface is bigger, namespace code younger, so more CVEs to chase.
As a result, if you're looking for good security isolation, I'd say a (Micro)VM is a better option. The other route is hardening down your container runtime with seccomp/AppArmor/SELinux but that can be a tricky game.