Container Internals Deep Dive 07: Rootless Containers with Podman
How rootless containers work with user namespaces, and where Podman fits in secure workflows.
On this page
Container Internals Deep Dive — this post is part of a series
- Part 1: Container Internals Deep Dive 00
- Part 2: Container Internals Deep Dive 01: Cgroups
- Part 3: Container Internals Deep Dive 02: Namespaces
- Part 4: Container Internals Deep Dive 03: Network Namespaces and CNI
- Part 5: Container Internals Deep Dive 04: containerd Internals
- Part 6: Container Internals Deep Dive 05: OCI Standard
- Part 7: Container Internals Deep Dive 06: runc vs crun
- Part 8: Container Internals Deep Dive 07: Rootless Containers with Podman
- Part 9: Container Internals Deep Dive 08: Kata Containers
- Part 10: Container Internals Deep Dive 09: Firecracker microVM
Series: 8/10. In part 06 we compared runc and crun. Here we focus on rootless containers.
Rootless mode runs container workloads without host root privileges. This reduces host compromise impact.
Core mechanics #
- user namespaces map container UIDs to unprivileged host ranges
- root inside container != root on host
- networking often uses slirp4netns or rootless CNI variants
- storage uses user-scoped paths instead of global daemon paths
Why Podman is common here #
Podman supports daemonless workflows and rootless operation out of the box. It is popular for developer desktops, CI workers, and hardened multi-user environments.
Typical setup checks #
podman info --debug
cat /etc/subuid
cat /etc/subgid
If subordinate ID mappings are missing, rootless container creation will fail or degrade.
Tradeoffs to understand #
- Some kernel/network features have limitations in rootless mode.
- Throughput can differ from rootful networking paths.
- Debugging path differs from daemon-centric Docker setups.
Takeaway #
Rootless containers are one of the highest-leverage hardening steps when the workload model allows it.