Container security on NodeOps Network Compute

Our Approach to User Namespaces and User IDs

At NodeOps Network, we know that container security is fundamental to trust and reliability in our verifiable, decentralized Compute Marketplace. This article examines how user privileges work inside containers and presents how NodeOps leverages modern Linux features to protect you and your workloads.

Let’s break down the basics of user namespaces, user IDs, and privileges, then explain how NodeOps applies these principles for maximum security.

Why User Privileges Matter in Containers

Containers share the host’s Linux kernel. If a process inside a container runs as root (user ID 0), and there’s a vulnerability, that process could potentially compromise the host. That’s why managing user privileges is a critical part of container security.

What are the options?

There are three options available when running containers as shown in the diagram.

Let’s break these down.

1. No User Namespace (UserNS) mapping

Container A (uid=0/root) ─┐

├──> Host (uid=0/root)

Container B (uid=0/root) ─┘

How it works:

User IDs inside the container are mapped directly to the same IDs on the host. Root in the container is root on the host.

Risk:

If an attacker breaks out of the container, they become root on the host. Running containers as root (without namespaces) exposes your host to serious risks. Using user namespaces or rootless containers reduces the risk of attackers gaining elevated privileges if they escape a container.

2. User Namespace Remapping

Container A (uid=0/root) ─> Host (uid=1000/userA) (Non Root UID)

Container B (uid=0/root) ─> Host (uid=1001/userB) (Non Root UID)

How it works:

User namespaces remap container UIDs to different, non-privileged UIDs on the host. Root inside the container (uid=0) maps to a non-root user (like uid=1000) on the host.

Benefit:

If an attacker escapes, they don’t get root—they get a limited user.

3. Rootless Containers: a special case User Namespace remapping

Container A (uid=1000/userA) ─> Host (uid=1000/userA)

Container B (uid=1001/userB) ─> Host (uid=1001/userB)

How it works:

Containers are started by a non-root user on the host, and all container processes map to that user. Both the Docker daemon and containers run inside a user namespace, mapping the user’s UID (e.g., 1000) as root inside the container. This is very similar to userns-remap, but with the key difference that no process ever runs as host root — not even the daemon.

Benefit:

No root privileges are involved, even if something goes wrong.

What is the NodeOps Network Compute approach?

At NodeOps Network, we design our Protocol and infrastructure to maximize the balance between security and compatibility. Here’s how we handle user namespaces and user ID:

User Namespace isolation

NodeOps requires that all Compute workloads run in isolated user namespaces by default: taking a similar approach to the latest Kubernetes version. This means that even if a containerized workload runs as root inside the container, it is mapped to an unprivileged user on the host. This dramatically reduces the risk of privilege escalation.

Mapped user IDs:

We use remapping so that the root in the container is not the root on the host. This is enforced for all provider machines registered on the network.

The remapping means that even if a vulnerability is exploited, the attacker cannot gain root access to the host system, protecting both the provider and the wider network.

Rootless containers: a suboptimal solution

What about the third option, forcing all templates on NodeOps Network to use rootless containers? Well, there are several advantages to applying this approach, summarized in the table.

However, while rootless containers offer the highest level of isolation, their adoption is often limited by compatibility and legacy application requirements. Many existing container images and workloads are designed with the expectation that they will run as root inside the container. As a result, some software simply won’t function correctly in a rootless environment without significant modification, making migration challenging for established teams and projects.

Another challenge is the narrow range of ecosystem support for rootless containers. Not all third-party tools—such as orchestration platforms, monitoring agents, or networking plugins—fully support rootless operation yet. Additionally, rootless containers may not offer the full range of Docker or Kubernetes features, such as certain networking modes, volume mounts, or privileged operations. Some workloads also require direct access to devices or kernel features that are restricted in rootless mode, further limiting their applicability for certain use cases.

Running containers in rootless mode can also introduce additional complexity. The extra layers of user and group ID mapping required for rootless operation can result in performance overhead, such as slower file system access. Operationally, managing rootless environments can be more complicated, especially when integrating with existing CI/CD pipelines, storage solutions, or system services that assume root-level access.

Finally, while rootless container technology is advancing rapidly, it is still maturing compared to user namespace remapping, which is more widely tested and stable in production environments. User namespace remapping already provides a strong security boundary by ensuring that the container root does not equate to the host root. This approach strikes a practical balance between security, compatibility, and usability, making it the preferred choice for many organizations today.

At NodeOps, we believe security should be built-in and automatic. By leveraging user namespaces and remapping user IDs, we protect both Compute providers and the Network.

Ready to deploy securely?

Check out our documentation for technical details and step-by-step guides.