Introduction to Container Isolation and the Root Dilemma

In modern cloud infrastructure, Docker has become the standard for deploying applications efficiently across Virtual Private Servers (VPS). However, this convenience introduces a critical, often overlooked security vulnerability: by default, the root user inside a Docker container is the exact same root user (UID 0) on the host system.

While Linux containers use namespaces to restrict what a containerized process can see, they do not inherently restrict what that process is. If an application inside a container is compromised and an attacker exploits a kernel vulnerability or a misconfigured volume mount, they can break out of the container. Because they are running as UID 0, they immediately inherit absolute, unrestricted administrative privileges over your entire VPS host. This is known as a privilege escalation attack, and it represents one of the most severe threats to containerized environments.

To mitigate this risk, enterprise-grade security architectures rely on Docker User Namespaces (userns-remap). This advanced configuration isolates the host’s user definitions from the container’s user definitions, effectively neutralizing container breakout exploits.

Understanding User Namespaces (userns-remap)

The Linux User Namespace feature allows a range of automated User IDs (UIDs) and Group IDs (GIDs) inside a container to be mapped to a completely different, non-privileged range of UIDs and GIDs on the host system.

When User Namespaces are enabled in Docker:

The process inside the container believes it is running as the almighty root (UID 0).
On the underlying VPS host, that exact same process is seen and treated as an unprivileged, high-number UID (e.g., UID 165536).

The Security Impact: If a hacker successfully exploits an application vulnerability, bypasses container boundaries, and achieves a 'container breakout', they land on your VPS host not as root, but as a completely unprivileged user with zero permissions to modify system files, access other containers, or control the host OS.

Prerequisites for Implementation

Before modifying your production environment, ensure your system meets the following requirements:

A VPS running a modern Linux distribution (Ubuntu 22.04 LTS, Debian 12, or RHEL 9 are highly recommended).
Docker Engine installed and running (Community or Enterprise Edition).
Sudo or root access to the host operating system.
A clear understanding that enabling User Namespaces alters how file permissions work on volume mounts (which we will address below).

Step-by-Step Configuration Guide

Follow these precise technical steps to implement User Namespaces across your Docker infrastructure.

Step 1: Verify and Configure SubUID and SubGID Allocations

Linux manages subordinate user and group IDs via two configuration files: /etc/subuid and /etc/subgid. When you install Docker, it usually creates a system user named dockremap. We must ensure this user has an assigned range of UIDs and GIDs.Check the files using the following commands:

cat /etc/subuid
cat /etc/subgid

You should see an entry similar to this:

dockremap:165536:65536

This entry means that the user dockremap is allocated a range of 65,536 subordinate IDs, starting at UID 165536. Inside the container, UID 0 (root) will map to host UID 165536, UID 1 will map to host UID 165537, and so on.

If these entries do not exist, you can create them manually by running:

sudo groupadd dockremap
sudo useradd -g dockremap dockremap
echo "dockremap:165536:65536" | sudo tee -a /etc/subuid
echo "dockremap:165536:65536" | sudo tee -a /etc/subgid

Step 2: Enable User Namespaces in the Docker Daemon

Next, we must instruct the Docker daemon to utilize the dockremap configuration. This is achieved by modifying the global Docker daemon configuration file located at /etc/docker/daemon.json.

Open or create the file using your preferred text editor:

sudo nano /etc/docker/daemon.json

Add the userns-remap directive to the configuration object:

{
  "userns-remap": "default"
}

Using "default" tells Docker to specifically look for the dockremap user we verified in Step 1. Save and close the file.

Step 3: Restart the Docker Service

For the changes to take effect, restart the Docker systemd service:

sudo systemctl restart docker

Note: Existing containers will not be automatically transferred to the new namespace. Docker will initialize a new, isolated storage directory structure specifically for the namespaced containers, typically located under /var/lib/docker/165536.165536/.

Verification: Testing the Security Isolation

To verify that User Namespaces are active and working as intended, spin up a new, lightweight test container:

docker run -d --name security_test alpine sleep 300

Now, check the process status from the perspective of the VPS host using the ps command:

ps aux | grep sleep

You will observe an output similar to this:

165536   12345  0.0  0.0   1500    4 ?        Ss   10:00   0:00 sleep 300

Notice the first column (the user running the process). Inside the container, running whoami would return root. However, as demonstrated by the host process table, the process is safely bound to host user 165536. The isolation is successful.

Managing the Challenges: Volume Bind Mounts and Permissions

While User Namespaces dramatically elevate security, they introduce a practical operational hurdle: file permission mismatches on volume mounts.

If you mount a directory from your VPS host (e.g., /var/www/html owned by host root 0:0) into a namespaced container, the container's root user (mapped to UID 165536) will see the files but will face Permission Denied errors when trying to write to them. This is because host UID 165536 does not have write access to files owned by host UID 0.

The Solution: Chown to the Repped UID

To grant your containerized application access to the host directory, you must explicitly change the ownership of the host directory to the mapped UID/GID range:

sudo chown -R 165536:165536 /var/www/html

By executing this change, the containerized application can read and write files natively, while the host system remains fully protected because UID 165536 holds no dangerous privileges outside that specific directory.

Conclusion and Best Practices

Configuring User Namespaces is one of the most effective defensive strategies against container escape and privilege escalation attacks on your VPS infrastructure. By breaking the direct link between container root and host root, you ensure that an application-level breach does not translate into a full system compromise.

As you scale your Docker infrastructure, combine User Namespaces with these additional hardening techniques:

Run as non-root anyway: Even with userns enabled, configure your Dockerfiles to use a non-root USER directive to enforce defense-in-depth.
Set read-only root filesystems: Use the --read-only flag when running containers to prevent malicious binaries from being written to the container lifecycle.
Drop unnecessary Linux capabilities: Use --cap-drop=ALL and selectively add back only what the application explicitly requires.

By investing the time to properly set up user remapping, you shift your container infrastructure from a default, vulnerable state to a hardened, resilient environment capable of withstanding modern security threats.

Advanced Docker Infrastructure Security: Implementing User Namespaces on VPS to Eliminate Privilege Escalation Risks