Running Containers Safely with Podman’s Rootless Mode

The problem: privileged daemons in multi‑tenant settings

Many teams want to run container workloads without exposing a privileged daemon that runs as root. A traditional Docker engine requires either root access or a daemon that holds elevated capabilities, which complicates security hardening in shared developer workstations, CI agents, or edge nodes. The goal is to obtain the same ergonomics as Docker while reducing the attack surface.

Thesis: Podman’s rootless mode provides a daemon‑less, user‑namespace‑based alternative

Podman can create and manage containers entirely inside an unprivileged user’s UID/GID range by leveraging Linux user namespaces, subordinate ID mappings, and slirp4netns for networking. No central daemon runs as root, and the user experience mirrors the Docker CLI.

How rootless Podman works

When a user invokes podman, the following steps occur:

1. The process requests a new user namespace. The kernel maps a range of subordinate UIDs and GIDs defined in /etc/subuid and /etc/subgid to the namespace’s UID 0.
2. A separate network namespace is created; traffic is routed through slirp4netns, an unprivileged user‑space TCP/IP stack.
3. The container’s root filesystem is mounted with overlayfs, using a private storage directory under the user’s home (~/.local/share/containers).
4. All subsequent container processes run inside these isolated namespaces, appearing as UID 0 inside the container but mapped to a non‑root UID on the host.

Setting up rootless Podman on a Linux workstation

Assuming a recent distribution that ships the podman package:

1. Install Podman (e.g., sudo dnf install podman on Fedora or sudo apt-get install podman on Ubuntu).
2. Allocate subordinate ID ranges for the user. Choose a range that does not overlap with existing system UIDs/GIDs, for example 100000‑165535:

# Replace $USER with the actual login name
sudo sh -c 'echo "$USER:100000:65536" >> /etc/subuid'
sudo sh -c 'echo "$USER:100000:65536" >> /etc/subgid'

After editing, the user must start a new login session (or run newuidmap/newgidmap) for the changes to take effect.
Worked example: running a container and verifying the user namespace
Run a simple Alpine container that prints the effective user inside the container and the host UID mapping:
podman run --rm --userns=keep-id alpine sh -c 'whoami; id -u'

Expected behavior (do not treat as guaranteed output): the command prints the host username followed by 0, indicating that inside the container the process has UID 0 while being mapped to the subordinate range on the host.
To confirm the namespace mapping explicitly, inspect the UID map:
podman run --rm --userns=keep-id alpine cat /proc/self/uid_map

You should see a line similar to 0 100000 65536, showing that container UID 0 maps to host UID 100000 with a size of 65536.
Trade‑offs and limitations

  
Networking overhead: Because traffic goes through slirp4netns, throughput and latency are slightly higher than with a bridged or host‑network mode. For most developer workloads this is acceptable; high‑performance services may need to evaluate the impact.
  
Privileged capabilities: Operations that require capabilities such as SYS_ADMIN (e.g., mounting certain filesystems) or direct device access are not available unless the device is explicitly exposed with --device and the user namespace is configured to allow it.
  
Subordinate ID configuration: Incorrect or overlapping ranges in /etc/subuid//etc/subgid will cause container start‑up failures. Regularly audit these files, especially when multiple users share a machine.

Actionable closing
Enable rootless Podman on developer workstations by installing the package, allocating appropriate subordinate ID ranges, and verifying the setup with the UID‑map check shown above. In CI pipelines, replace Docker‑in‑Docker steps with Podman rootless commands to gain the same security benefits without redesigning container images. Periodically re‑run the verification steps after system updates to ensure the user namespace remains functional.