Choosing Between Rootless and Root-full Podman for Production

The Security vs. Performance Trade-off

When deploying Podman, the primary engineering decision is whether to run containers as the root user (root-full) or as an unprivileged user (rootless). The core problem is balancing the security risk of a container breakout against the networking performance and privilege requirements of the application.

In root-full mode, the Podman process runs as the host's root user. If an attacker escapes the container, they potentially inherit root privileges on the host. Rootless mode mitigates this by using User Namespaces—a Linux kernel feature that maps a range of UIDs (User IDs) and GIDs (Group IDs) from the host to the container. Inside the container, the process appears as root, but on the host, it is mapped to a standard, unprivileged user.

Comparison of Execution Modes

Feature	Rootless Mode	Root-full Mode
Host Privilege	Unprivileged User	Root User
Networking	slirp4netns (User-mode)	Direct Bridge/Host
Privileged Ports	Blocked (< 1024) by default	Allowed
Kernel Caps	Restricted (e.g., no CAP_SYS_ADMIN)	Full Access
Performance	Higher network latency	Native performance

Engineering Trade-offs

Security: Rootless is the gold standard for multi-tenant environments or applications facing the public internet. It ensures that a vulnerability in the container runtime or the application does not lead to a full host compromise.

Networking: Rootless containers use slirp4netns, which emulates a network stack in user space. This introduces overhead. For high-throughput database workloads or low-latency APIs, root-full mode is often preferred to avoid this bottleneck.

Configuration: Rootless mode requires the host to have /etc/subuid and /etc/subgid configured. These files tell the kernel which range of subordinate IDs the user is allowed to use to simulate multiple users inside the container.

Implementing Rootless Podman

To implement rootless containers, you must first ensure the user has a subordinate ID range. This is typically handled by the shadow-utils package on most Linux distributions.

Step 1: Verify Subordinate IDs
Run this command as a user with sudo privileges to ensure the target user (e.g., appuser) has a range assigned:

grep appuser /etc/subuid
# Expected output: appuser:100000:65536

Step 2: Validate User Namespace Mapping
Run the following as the appuser to verify the current user is mapped to root within the namespace:

podman unshare id
# Expected output: uid=0(root) gid=0(root) groups=0(root)

Step 3: Deploy and Verify Container Identity
Run a lightweight container to check the identity mapping. Run this as the appuser:

podman run --rm alpine id
# Expected output: uid=0(root) gid=0(root) groups=0(root)

To verify that this "root" user is actually unprivileged on the host, check the process list from a separate root terminal:

ps -ef | grep alpine
# The process will be owned by 'appuser', not 'root'.

Handling Privileged Port Limitations

By default, rootless containers cannot bind to ports below 1024. If your application requires port 80 or 443, you have two options:

• Port Mapping: Map a high port in the container to a high port on the host (e.g., -p 8080:80) and use a load balancer or firewall to redirect traffic.
• Sysctl Modification: Lower the unprivileged port threshold on the host. Run this as root:

sysctl -w net.ipv4.ip_unprivileged_port_start=80

Limitations and Verification

Rootless mode cannot perform operations requiring CAP_SYS_ADMIN, such as mounting certain filesystems or modifying kernel parameters. If your container fails with "Permission Denied" despite being root inside the container, check if the required kernel capability is restricted.

Verification Check: To confirm the container is running rootless, execute podman info | grep -i rootless. It should return rootless: true.