Rootless containerd

No Root Required Enhanced Security User Namespaces

Rootless containerd allows running the container runtime and containers without root privileges on the host. This significantly improves security by reducing the attack surface and impact of container escapes.

Rootless Mode Enhanced Security User Namespaces

What is Rootless containerd?

Rootless containerd is a mode that allows the containerd daemon and containers to run without root privileges on the host system. In traditional containerd, the daemon runs as root, creating a potential security risk—if a container escapes, the attacker gains root access on the host. Rootless containerd runs the daemon and containers in a user namespace, mapping container root (UID 0) to an unprivileged user on the host.

This significantly reduces the impact of a container escape. Even if an attacker breaks out of a container, they only gain the privileges of the user running containerd, not root. Rootless mode is a major security improvement, especially for multi-tenant environments or untrusted workloads.

Rootless containerd is available in containerd v1.4 and later. It's production-ready for many workloads but has some limitations compared to rootful containerd.

How Rootless containerd Works

Rootless containerd leverages Linux user namespaces, a kernel feature that allows a non-root user to act as root inside a namespace while remaining unprivileged outside. The containerd daemon runs as your user, and containers run inside a user namespace where UID 0 (root) is mapped to your unprivileged host UID.

Additionally, Rootless containerd uses several other technologies: slirp4netns for network connectivity, fuse-overlayfs for storage (or native overlayfs with kernel support), and cgroup v2 for resource limits (optional).

                # Check if user namespaces are supported
cat /proc/sys/user/max_user_namespaces

# Check kernel version (needs 4.18+ for full support)
uname -r

# Verify rootless mode is active
containerd --version
containerd config dump | grep -i rootless

# Check mapping of container root to host user
cat /proc/self/uid_map
            

Installing Rootless containerd

Installing Rootless containerd is straightforward. You don't need to uninstall regular containerd—rootless can run alongside it.

                # Install rootless containerd (Ubuntu/Debian)
curl -fsSL https://get.docker.com/rootless | sh

# Or manually install
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh --dry-run
sh get-docker.sh --disable-rootless=false

# Add to PATH in your shell config (~/.bashrc)
export PATH=/home/$USER/bin:$PATH
export CONTAINERD_NAMESPACE=default

# Start rootless containerd service
systemctl --user start containerd
systemctl --user enable containerd

# Verify installation
containerd --version
containerd config dump | grep -i rootless
            

After installation, containerd commands work the same way, but the daemon runs without root privileges. Use `containerd config dump` to confirm rootless mode.

Rootless vs Rootful containerd

Security

Rootless: Daemon runs as unprivileged user. Container escape gives unprivileged access.

Rootful: Daemon runs as root. Container escape gives root access.

Cgroup Support

Rootless: Limited (cgroup v2 only, requires delegation)

Rootful: Full (cgroup v1 and v2)

Networking

Rootless: slirp4netns (overhead)

Rootful: Native networking

Kubernetes Integration

Rootless: Limited (no overlay networks, host networking)

Rootful: Full support

Storage

Rootless: fuse-overlayfs (slower) or overlayfs (with kernel support)

Rootful: Native overlayfs

Use Case

Rootless: Development, CI/CD, multi-tenant environments

Rootful: Production, Kubernetes clusters, performance-critical workloads

Enabling Cgroup v2 for Resource Limits

For resource limits (memory, CPU, pids) to work in rootless containerd, your host must use cgroup v2. Most modern Linux distributions now use cgroup v2 by default (Ubuntu 22.04+, Fedora 31+, Debian 11+).

                # Check cgroup version
mount | grep cgroup2
# If output shows cgroup2, you're on v2

# Or check
stat -fc %T /sys/fs/cgroup/
# "cgroup2fs" means v2, "tmpfs" means v1

# Enable cgroup v2 (Ubuntu - requires reboot)
# Edit kernel command line in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="systemd.unified_cgroup_hierarchy=1"

# Update grub
sudo update-grub
sudo reboot

# For rootless containerd, enable delegation
sudo mkdir -p /etc/systemd/system/user@.service.d
cat <
            



        
        
            
                
                Limitations of Rootless containerd
            
            
                No host network mode - `--network host` doesn't work because the container can't access the host's network stack.
                No privileged containers - `--privileged` flag is not supported (security feature).
                Cgroup v2 required - For resource limits (CPU, memory), you need cgroup v2 enabled on the host.
                Performance overhead - Network has overhead due to slirp4netns (though usually acceptable).
                No AppArmor/SELinux profiles - These LSM features don't work in rootless mode.
                Storage driver limitations - Overlayfs requires extra configuration; fuse-overlayfs works but has overhead.
                No Kubernetes support for overlay networks - Swarm and overlay networks are not supported.
            
            
                 Rootless containerd is not a drop-in replacement for all workloads. Test your specific use cases before deploying in production.
            
        

        
        
            
                
                When to Use Rootless containerd
            
            
                Multi-tenant environments - Different users can run containerd independently without root access.
                Shared development servers - Developers can run containers without needing sudo or root access.
                CI/CD runners - Reduce security risk from untrusted code running in pipelines.
                Education and training - Students can learn containers without root access.
                High-security environments - Where container escape is a major concern.
                Personal workstations - Safer default for everyday container usage.
            
            
                 For most development and CI/CD use cases, rootless containerd is a great choice. For production Kubernetes clusters, use rootful containerd with proper security measures.
            
        

        
        
            
                
                Troubleshooting Rootless containerd
            
            
                # Check if rootless mode is active
containerd config dump | grep -i rootless

# View rootless daemon logs
journalctl --user -u containerd -f

# Check user namespace support
cat /proc/sys/user/max_user_namespaces
# If 0, enable with: sudo sysctl -w user.max_user_namespaces=10000

# Check cgroup support
cat /sys/fs/cgroup/memory/memory.limit_in_bytes

# Reset rootless containerd
systemctl --user stop containerd
rm -rf ~/.local/share/containerd
systemctl --user start containerd

# Check slirp4netns
which slirp4netns
sudo apt install slirp4netns  # if missing
            
        

        
        
            
                
                Frequently Asked Questions
            
            
            
                 Is rootless containerd production-ready?
                For many workloads, yes. However, limitations like no host networking and limited cgroup support mean it's not suitable for all production scenarios. Test thoroughly before deploying.
            
            
            
                 Can I run both rootful and rootless containerd on the same machine?
                Yes! They use different socket paths and storage locations. Rootful uses `/var/run/containerd/containerd.sock`, rootless uses `/run/user/$UID/containerd/containerd.sock`.
            
            
            
                 Does rootless containerd work on macOS/Windows?
                No. Rootless containerd is a Linux-only feature. It requires Linux user namespaces, which aren't available on macOS or Windows.
            
            
            
                 What's the performance impact of rootless mode?
                Network has some overhead (slirp4netns), typically 5-15%. Storage may have overhead if using fuse-overlayfs. For CPU/memory intensive workloads, the difference is minimal.
            
            
            
                 Can I use containerd with rootless mode and Kubernetes?
                Yes, but with significant limitations. Overlay networks, host networking, and privileged containers are not supported. Rootless containerd is not recommended for production Kubernetes clusters.
            
            
            
                 Do I need to add my user to any special groups for rootless?
                No! Rootless containerd doesn't require any special group membership. This is a security benefit—users can run containers without any special privileges.
            
            
            
                 Why does my container have slow network in rootless mode?
                Rootless uses slirp4netns for networking, which has higher latency than native networking. For better performance, ensure you have the latest slirp4netns version.
            
            
            
                 Should I use rootless containerd for production?
                For single-node production applications that don't need host networking or privileged containers, yes. For multi-node Kubernetes clusters, use rootful containerd with proper security hardening.
            
        

        
        
             Previous: containerd Logging
             Next: Performance Tuning
        
        
         Rootless containerd significantly improves container security by eliminating root privileges. While it has limitations, it's an excellent choice for development, CI/CD, and many production workloads.