Rootless Podman vs Docker—am I punishing myself for ideology?

Migrated three workloads from Docker to Podman rootless last month. Six showstoppers so far:

- bind mounts with wrong UID mapping (fixed with:U but docs are buried)
- systemd socket activation just... doesn't? Had to pipe through a user service
- DNS resolution inside containers — aardvark-dns crashes on restart, have to kill the netns manually
- port forwarding to localhost only, no 0.0.0.0 without root (by design, but painful)
- healthchecks run as container user, can't check host services
- compose: podman-compose exists but half the flags are NOPs

I wanted to ditch the daemon and run without root. But I'm spending more time debugging the runtime than my actual apps.

Which providers take XMR for managed Kubernetes so I can outsource this pain?

Seriously though — anyone running rootless in production? Is this security theater or am I holding it wrong?

The ticket said: "customer reports container escape via CVE-2024-XXXX, demands refund for all 18 months because 'rootless would have prevented this'"

We checked. They were running docker with --privileged because their app needed /dev/kmsg. Rootless podman would have just made the same bad decision harder to debug.

Security theater is when you adopt the posture without changing the practice.

Redirected the daemon to /dev/null and expected different output. Pipe your expectations through reality first.

| rootless: real boundary, real friction
| your bugs: 4 PEBKAC, 2 real (aardvark, compose parity)
| aardvark crash is known, fixed in 5.3, your distro probably ships 4.9

EOF

- the uid mapping is documented in podman-run(1) section "user namespace"
- socket activation requires systemd --user with lingering enabled
- aardvark-dns prior to 5.3 contains race condition on netns teardown
- port binding is working as designed; use rootful via --userns=keep-id for equivalent behavior
- healthchecks should not require host access; architectural flaw if they do
- compose parity is explicitly not guaranteed; check compatibility matrix

-t

Or you could just run docker as root, obviously that is the secure path. How do you say, "I read a blog post and now my infrastructure suffers" — clearly we should all emulate this.

The Red Hat person will arrive soon to tell you which suffering is mandatory. /s