Securing Podman with Rootless Containers: User Namespace Configuration

The Rootless Security Advantage

Running containers as root creates a significant security risk: if a process escapes the container, it inherits root privileges on the host machine. Podman solves this by using Rootless Mode, which leverages User Namespaces (user_ns) to map a non-privileged host user to the root user inside the container. The primary takeaway is that in rootless mode, the container's "root" is actually a standard user on the host, meaning a container breakout grants the attacker only the permissions of that specific user, not administrative control over the OS.

How User Namespaces Map Identities

To achieve rootless execution, Podman requires a range of subordinate User IDs (UIDs) and Group IDs (GIDs) that the host kernel allows the user to manage. These are defined in /etc/subuid and /etc/subgid.

When you start a rootless container, Podman creates a new user namespace. It maps your current host UID (e.g., 1000) to UID 0 (root) inside the container. It then maps a range of subordinate IDs (e.g., 100,000 to 165,535) to the remaining UIDs inside the container (1 to 65,535). This ensures that files created by the container are owned by IDs that the host user is authorized to manage, but which do not overlap with other actual users on the system.

Example: Configuring Subordinate IDs

Before running rootless containers, you must ensure your user has an assigned range of IDs. This typically requires root permissions on the host for the initial setup.

1. Assign subordinate IDs
Run the following command as root or via sudo on the host machine, replacing username with your actual account name:

# Syntax: usermod --add-subuids [START]:[COUNT] username
sudo usermod --add-subuids 100000:65536 username
sudo usermod --add-subgids 100000:65536 username

2. Verify the configuration
Check the configuration files to ensure the entries were written correctly:

cat /etc/subuid
# Expected output: username:100000:65536

3. Launch a rootless container
Run a simple container as the non-privileged user:

podman run --rm alpine echo "Hello from rootless"

Networking and Port Limitations

Because rootless containers do not have permission to manipulate the host's iptables or create network interfaces, Podman uses slirp4netns. This is a user-mode network stack that emulates a network interface.

The Privileged Port Constraint

By default, Linux prevents non-root users from binding to "privileged" ports (those below 1024). If you try to map host port 80 to a container, the operation will fail.

Solution: You can lower the unprivileged port threshold via sysctl. Run this as root on the host to allow users to bind to ports starting at 80:

sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80

Verification and Diagnostics

To confirm your environment is operating in rootless mode and the mapping is active, use these diagnostic checks:

• Check Infrastructure Status: Run podman info. Look for the rootless: true flag under the infrastructure section.
• Inspect UID Mapping: Run podman unshare cat /proc/self/uid_map. This command enters the user namespace and displays how the host IDs map to container IDs.

Common Pitfalls and Limitations

Limitation	Impact	Workaround/Note
Network Performance	Higher latency/lower throughput than rootful bridge networking.	Use --net=host if the application requires maximum performance and security risks are managed.
Storage Drivers	Some older kernels do not support overlayfs in rootless mode.	Podman may fallback to vfs, which is significantly slower and uses more disk space.
Volume Permissions	Files mounted from the host may appear as nobody:nobody inside the container.	Use podman unshare chown to adjust host file ownership to match the subordinate UID range.