29.2a Why Docker is not used in HPC: root requirement and security model¶
📘 Context Introduction¶
In High-Performance Computing (HPC) environments, containers are essential for packaging software, dependencies, and workflows. While Docker is the most popular container platform in cloud and enterprise settings, it is rarely used in HPC clusters. The two primary reasons are Docker's requirement for root privileges and its security model, which conflict with the multi-user, shared-resource nature of HPC systems. This section explains why Apptainer (formerly Singularity) is preferred over Docker in HPC.
⚙️ The Root Requirement Problem¶
Docker's architecture requires the Docker daemon to run with root (superuser) privileges. This creates several issues in HPC environments:
- Privilege escalation risk: Any user who can run Docker commands effectively gains root-level access to the host system.
- Shared cluster conflict: HPC clusters are shared by many users. Granting root access to one user compromises security for all others.
- No user namespace mapping: Docker containers run as root inside the container by default, which maps to root on the host — a major security violation in HPC.
Why this matters for new engineers: In HPC, you never want a user's container to have the same privileges as the system administrator. Apptainer solves this by running containers as the current user, not root.
🕵️ Security Model Comparison¶
Docker's security model is designed for isolation and multi-tenancy in cloud environments, not for shared HPC clusters. Here is how the two compare:
| Feature | Docker | Apptainer (Singularity) |
|---|---|---|
| Default user inside container | Root | Current user (non-root) |
| Daemon required | Yes (runs as root) | No (runs as user process) |
| Privilege escalation | Possible via Docker socket | Not possible |
| Kernel namespace isolation | Full (user, PID, network) | Minimal (filesystem only) |
| GPU access | Requires --gpus flag and root |
Native, no root needed |
| Multi-user safe | No | Yes |
📊 Visual Representation: Docker Root Daemon Security exploit¶
This diagram shows why HPC environments avoid Docker: container root privileges can exploit volume mounts to modify host root filesystems.
🛠️ Key Security Concerns with Docker in HPC¶
- Docker socket exposure: The Docker daemon listens on a Unix socket (
/var/run/docker.sock). Any user with access to this socket can run containers as root. - Container breakout risk: Docker's kernel namespace isolation can be bypassed, allowing a container to access the host system.
- No user identity preservation: Docker containers do not preserve the original user's identity (UID/GID), causing file permission issues on shared filesystems like Lustre or NFS.
- Network security: Docker creates virtual network interfaces that can interfere with HPC interconnects like InfiniBand or OmniPath.
🔄 How Apptainer Solves These Problems¶
Apptainer was designed specifically for HPC environments. Its security model addresses Docker's shortcomings:
- No daemon: Apptainer runs as a user-level process, eliminating the root daemon requirement.
- User identity preservation: The container runs with the same UID and GID as the user who launched it.
- Read-only container images: By default, container images are mounted read-only, preventing tampering.
- No privilege escalation: Apptainer containers cannot gain root access on the host, even if the container image contains a root user.
- Native HPC integration: Apptainer works seamlessly with Slurm, PBS, and other HPC schedulers without special permissions.
📊 Practical Implications for Engineers¶
When working in an HPC environment, keep these points in mind:
- You cannot run Docker directly on most HPC clusters — the system administrators will not allow it.
- You must use Apptainer (or another HPC-native container runtime like Charliecloud or Podman in rootless mode).
- Converting Docker images to Apptainer images is straightforward. Use the
apptainer buildcommand to convert a Docker image to a.sif(Singularity Image Format) file. - GPU workloads in HPC require Apptainer's
--nvflag (for NVIDIA GPUs) or--rocmflag (for AMD GPUs), which do not require root privileges.
✅ Summary¶
Docker is not used in HPC because its root requirement and security model are incompatible with shared, multi-user HPC clusters. Apptainer (Singularity) was created to address these issues by running containers as the current user, requiring no daemon, and preserving user identity. As a new engineer in AI Infrastructure and Operations, always use Apptainer when working with containers in HPC environments — it is the standard for a reason.
📝 Key Takeaway: In HPC, security and user isolation are non-negotiable. Docker's design assumes a single-administrator model, while HPC requires a multi-user, shared-resource model. Apptainer bridges this gap perfectly.