Rootless Podman: Architecture, Trade‑offs, and Decision Checklist

Problem Statement

Many teams want to run containers in CI pipelines or on shared workstations without granting users root privileges. Rootless Podman offers a way to launch fully isolated containers while keeping the host safe. This article maps the architectural decisions behind rootless mode, lists the minimal design needed to deploy it, identifies trust and data boundaries, and provides operational checks and failure‑mode guidance that influence whether a rootless deployment is appropriate.

Rootless Podman Architecture

Rootless mode relies on three kernel features:

• User namespaces – remap the container’s UID/GID space to the invoking user.
• Slirp4netns or user‑mode networking – provide network isolation without a privileged network stack.
• Unprivileged storage – the container image store lives under $HOME/.local/share/containers.

Because the process never runs as root, the attack surface is reduced: the container cannot directly access host devices, privileged capabilities, or host networking.

Operational Requirements

1. Kernel support – Linux kernel 4.8+ with user‑namespace support (most modern distributions meet this).
2. Podman 4.x or newer – earlier releases had incomplete rootless support.
3. Home directory writable – the image store and runtime files are created in the user’s home. Sufficient disk quota is required.
4. SELinux/AppArmor enabled – policies still apply; misconfiguration can block container start or expose the host.
5. Systemd‑user session – for podman‑systemd integration and unit management.

Minimal Suitable Design

For a lightweight CI runner that needs to pull and run a single image per job, the following minimal design suffices:

• podman system service --time=0 – runs a local Podman API daemon as the user.
• Image store under $HOME/.local/share/containers.
• Networking via slirp4netns (default). If the job requires higher throughput, consider user‑mode networking with --network host disabled.
• Optional podman play kube or podman compose for orchestrating multi‑container services.

Trust & Data Boundaries

Boundary	What is isolated	Why it matters
User Namespace	UID/GID mapping, /proc, /dev inside the container	Prevents the container from seeing or affecting host users and processes.
Image Store	Images and layers in $HOME/.local/share/containers	Containment of potentially untrusted code; the user can delete or inspect layers.
Network	Slirp4netns/UDP/TCP traffic via user‑mode proxy	Blocks direct access to host interfaces; all traffic goes through a user‑space proxy.
File System	Only paths explicitly bind‑mounted are shared	By default, the container’s filesystem is read‑only; write access is limited to mounts.
SELinux/AppArmor	Policy context applied to the container process	Ensures that even if the container escapes the user namespace, it cannot read host files outside its allowed context.

Operational Checks

1. Verify Podman Version

   podman --version
   # Expect: Podman 4.x or newer
   

2. Confirm Rootless Execution

   podman run --rm -ti --rootless alpine whoami
   # Output should be the invoking username, not "root"
   

3. Check User Namespace Mapping

   cat /proc/self/ns/user
   # Should show a non‑root namespace
   unshare -U -- /bin/sh -c "id"
   # Output: uid=1000(...) gid=1000(...)
   

4. Validate Image Signing

   podman pull quay.io/containers/podman
   podman image verify quay.io/containers/podman
   # Should report "Signature verified: true"
   

5. Review SELinux Context

   podman run --rm -ti alpine ls -Z /var/log
   # Ensure the container can only see allowed contexts
   

Failure Modes

• Privilege‑Escalation Attempt – Running --privileged or attempting to mount /dev will fail with "permission denied". This is intentional but can cause confusion if users expect Docker‑style behaviour.
• Network Performance Degradation – User‑mode networking introduces latency and throughput limits (~10 Mbps for TCP). Heavy I/O workloads may stall.
• Disk Quota Exhaustion – Large images accumulate in the user’s home. Monitor du -sh $HOME/.local/share/containers and set quotas if needed.
• SELinux Policy Mis‑match – Incorrect policy can block container start or cause unexpected denials. Use audit2why to debug.
• Missing slirp4netns binary

When to Re‑evaluate the Design

Use the following conditions as triggers to consider a rootful or alternative deployment:

• Application requires privileged mode (e.g., Docker socket access, --cap-add=SYS_ADMIN).
• Network throughput must exceed the limits of user‑mode networking.
• Container needs to bind‑mount host devices (/dev/sda, /dev/tty, etc.).
• Image store size regularly approaches or exceeds the user’s disk quota.
• SELinux/AppArmor policies cannot be adapted to allow required access without weakening security.

Concrete Example: CI Runner with Rootless Podman

Below is a step‑by‑step setup for a GitHub Actions runner that uses rootless Podman to build and test a Go project.

1. Install Podman

   # Debian/Ubuntu
   sudo apt-get install podman
   

2. Configure User Namespace

   echo "userns=keep-id" | sudo tee /etc/containers/containers.conf
   

3. Set Up Image Store

   mkdir -p $HOME/.local/share/containers
   chmod 700 $HOME/.local/share/containers
   

4. Run CI Job

   podman run --rm -ti --rootless -v $(pwd):/workspace -w /workspace alpine sh -c \
   'apk add --no-cache git go && \
   go build ./... && \
   go test ./...'
   

5. Check Build Artifacts

   podman run --rm -ti --rootless -v $(pwd):/workspace alpine ls /workspace
   

All steps run without sudo and the container cannot affect the host beyond the mounted workspace.

Conclusion

Rootless Podman is a robust, low‑privilege container runtime ideal for developers, CI pipelines, and shared workstations. By understanding its architecture, operational constraints, and failure modes, you can decide whether it meets your security and performance needs or if a rootful deployment is warranted.