Skip to main content
This guide explains how to use Docker inside a SUNK cluster with a technique known as Docker-in-Docker (DinD). This approach enables automated evaluations and lets you run benchmarks, such as SWE-bench, within your SUNK cluster. This guide is for cluster administrators who need to enable container-based workflows inside SUNK compute nodes. Before you begin, review the known security risks section so you understand the trade-offs this configuration introduces.
The solution presented in this guide requires enabling privileged Pods and disabling the AppArmor profile recommended for use in SUNK. This process grants elevated kernel capabilities and weakens isolation guarantees. See the known security risks section for more details.You are responsible for verifying that third-party code is safe to execute alongside your other workloads.

​
Enable Docker-in-Docker

To run Docker inside SUNK compute nodes, you must disable AppArmor and run privileged Pods. The following changes to the Slurm Helm chart install the Docker daemon on each compute node, mount persistent storage for Docker, and relax the security context so the daemon can operate. To disable AppArmor and run privileged Pods, edit the values.yaml file of the Slurm Helm chart. In the compute section of the slurm Helm chart:
  1. Create an s6 block to install and enable Docker.
  2. Add a volume mount for Docker using the volumeMount and volumes blocks.
  3. Under pyxis, apply the following settings:
    • Set pyxis.enabled to true.
    • Set pyxis.appArmorProfile to null to disable the AppArmor profile.
    • Set pyxis.podSecurityContext to null to remove the pod security context.
  4. Under securityContext, set securityContext.privileged to true. The result should resemble the following: 
    compute:
  s6:
    docker:
      type: longrun
      script: |
        #!/bin/sh
        curl -fsSL https://get.docker.com | sh
        dockerd
  volumeMounts:
  - mountPath: /var/lib/docker
    name: docker-storage
  volumes:
    - name: docker-storage
      emptyDir: {}
  pyxis:
    enabled: true
    appArmorProfile: null
    podSecurityContext: null
  securityContext:
    privileged: true
  5. Verify that the AppArmor profile is correctly disabled. Replace [SLURMD-NODE-NAME] with the name of your slurmd Pod. 
    kubectl describe po [SLURMD-NODE-NAME] | grep LocalhostProfile
    This should return no output. If it outputs LocalhostProfile: profiles/enroot, then the configuration isn’t applied correctly.

​
Grant users Docker access

With the Helm chart changes applied, Docker is available on the compute nodes, but only root can use it by default. The next step grants non-root users the permissions they need to run Docker commands. After you disable AppArmor and enable privileged Pods, grant users access to Docker. If not running as root, users must belong to the sudoers group. If the SUNK cluster manages users with SUNK User Provisioning (SUP), set nsscache.sudoGroups to the groups that should have sudo privileges.

​
SUP-based clusters

For SUP-based clusters, configure nsscache: to provision access through SCIM, and list the sudo-enabled groups under sudoGroups:. Group names must exactly match the group names in CoreWeave IAM or your upstream IdP. Refer to the SUP documentation on creating user groups. 
 nsscache:
  sudoGroups:
   - slurm-sudo
   - additional-group

​
SSSD-based clusters

For SSSD-based clusters, set the sudoGroups: configuration in directoryService: to a list of Unix groups from all directories with sudo privileges.
  • The group names are not fully qualified for the default directory. For example, the default directory’s group name should be group1 instead of group1@example.com.
  • The group names are fully qualified for any additional directories.
directoryService:
  sudoGroups: ["slurm-sudo", "additional-group@example.com"]

​
Known security risks

Enabling Docker-in-Docker requires loosening several of SUNK’s default isolation guarantees. Before you apply the preceding configuration, review the risks in this section so you can decide whether the trade-offs are acceptable for your environment. Kubernetes provides a list of pod security standards. The following sections outline the subset most relevant to SUNK, but consider all of the standards listed in the Kubernetes documentation when assessing risk. The setup described in this guide:
  • Runs Docker inside a Pod.
  • Requires privileged mode.
  • Disables AppArmor protections.
This setup grants full access to the /proc and sys directories, and allows kernel-level operations, including mounting, pivoting root, and process tracing.

​
Item at risk: cgroups

cgroups handle management and monitoring of resources used by Slurm jobs. In privileged mode, users can bypass cgroup restrictions, reconfigure the resource limits set by Slurm, and move processes outside of their assigned cgroups. This is critical to understand when providing support for multi-tenancy in a single CKS cluster. The same guardrails you depend on for isolation do not apply here.

​
Item at risk: System and security

Disabling AppArmor on a privileged Pod removes additional security features, including protections against kernel exploits. This allows unrestricted access to the /proc and /sys directories. Without AppArmor protections in place, users can gain access to and tamper with other containers in the Pod, or access other devices outside the intended allocation.
Last modified on June 9, 2026