Implementing Rootless Containers with Podman for Host Security

The Security Risk of Rooted Daemons

Running container engines as a root-privileged daemon creates a significant attack surface. If a container escapes its isolation, the attacker inherits the privileges of the daemon—which, in traditional setups, is root access to the entire host. Podman solves this by utilizing User Namespaces, allowing users to launch and manage containers without requiring administrative privileges or a background daemon process.

Prerequisites for Rootless Operation

Before configuring Podman, the host system must support subordinate User IDs (UIDs) and Group IDs (GIDs). These allow the host to map a range of IDs to the container, making the container believe it is running as root while it remains a non-privileged user on the host.

• Podman Installed: Version 3.0 or later is recommended for stable fuse-overlayfs support.
• SubUID/SubGID Configuration: The user must have entries in /etc/subuid and /etc/subgid.
• Kernel Support: A Linux kernel that supports User Namespaces (standard in most modern distributions).

Configuring Subordinate IDs

To enable rootless mode, the system must allocate a range of IDs that the user can "own" inside the container. Run these commands as a user with sudo privileges to set up the target non-privileged user (replace username with the actual account name).

# Assign a range of 65,536 IDs starting at 100,000
sudo usermod --add-subuids 100000-165535 username
sudo usermod --add-subgids 100000-165535 username

Verification: Check the configuration files to ensure the mapping exists:

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

Deploying a Rootless Container

Once IDs are mapped, switch to the non-privileged user account. Podman will automatically detect the rootless environment and use fuse-overlayfs for storage and slirp4netns for networking.

1. Initialize the environment: Run a simple container to trigger the creation of the rootless storage graph.

   podman run --rm hello-world
   

2. Verify the rootless state: Check the Podman system information to confirm the mode.

   podman info | grep rootless
   # Expected output: rootless: true
   

3. Test ID Mapping: Run a container and check the identity inside versus outside.

   # Inside the container
   podman run --rm alpine id
   # Expected: uid=0(root) gid=0(root)
   
   # On the host (in a separate terminal while container is running)
   ps aux | grep podman
   # Expected: The process is owned by 'username', not 'root'
   

Handling Common Rootless Limitations

Rootless containers operate under specific constraints because they lack true kernel-level administrative access.

Constraint	Technical Cause	Practical Solution
Privileged Ports (<1024)	Linux prevents non-root users from binding to low ports.	Map to a high port (e.g., -p 8080:80) or modify net.ipv4.ip_unprivileged_port_start.
Network Performance	slirp4netns provides user-mode networking, adding overhead.	Use --net=host for high-performance needs (caution: reduces isolation).
Kernel Modules	User namespaces cannot load or modify kernel modules.	Load required modules on the host before starting the container.

Diagnostic Decision: Storage Driver Issues

If you encounter "permission denied" errors during image pulls in rootless mode, it is often due to the storage driver. Podman prefers overlay, but some filesystems require fuse-overlayfs.

To force fuse-overlayfs, edit ~/.config/containers/storage.conf:

[storage]
driver = "overlay"
[overlay]
mount_program = "/usr/bin/fuse-overlayfs"

Rollback and Cleanup

If you need to revert the rootless configuration for a specific user, remove the subordinate ID mappings and clear the local storage.

1. Remove sub-ID entries: sudo userdel -M username (or manually edit /etc/subuid and /etc/subgid).
2. Clear Podman local storage: podman system reset. This deletes all local images, containers, and volumes associated with that user.