The Slurm admin guide sets a few baseline expectations: authenticate every component with MUNGE, run most daemons as a non-root service account, accept that slurmd runs as root, keep user IDs consistent across nodes, and keep jobs off login nodes. Review those five before anything else.
Authentication
The Slurm administrator quick start says all communications between Slurm components are authenticated, and the AuthType setting selects the plugin. MUNGE is the default and recommended option. Every node must have the same munge.key file, and the munged daemon must start before the Slurm daemons. MUNGE also needs synchronized clocks, usually through NTP.
Since version 23.11.0 there is an alternative, auth/slurm, which needs a key file shared by all Slurm daemons.
What to check on your cluster:
- Who can read munge.key on each node?
- How is it distributed and rotated?
- Is time sync healthy on every node?
Privileges
Most Slurm daemons should run as a non-root service account, such as a slurm user set as SlurmUser. The exception is slurmd, which the guide says must run as root because it initiates and manages user jobs.
That makes compute nodes sensitive. Anything that lets a user run code as another user on a node, or tamper with the slurmd process, matters more here than on a typical server.
Identity consistency
The guide states that user and group IDs must be consistent across the cluster. If the same number maps to different people on two nodes, file permissions stop meaning what you think they mean. Check that your directory service feeds every node, including newly added ones.
Login nodes and compute access
The guide says login nodes should not have jobs scheduled on them, and gives a stated reason: users with root on their own machines could reach security keys directly. A PAM module can stop users from logging in to compute nodes that are not allocated to them.
Permissions at install time
Directories created during installation take permissions from the umask. The guide notes that a mask of 0000 yields world-writable directories and calls that a security problem. Check the permissions on Slurm spool and state directories after any rebuild.
A short review checklist
| Item | Question |
|---|---|
| MUNGE | Same key everywhere, readable only by the right account? |
| Service account | Does slurmctld run as non-root? |
| UIDs and GIDs | Consistent on every node? |
| Login nodes | No jobs, and no keys reachable by users? |
| Compute access | Restricted to allocated users? |
| Directories | Not world-writable? |
| Version | Is the Slurm release current for security fixes? |
The last row is not in the guide's text; treat it as ordinary patch hygiene and check your version against the vendor's release notes.
What a dependency scan adds
None of the above is a dependency question. But clusters also run user code and shared software on top of the scheduler, and that layer carries known vulnerabilities. Safeguard's dependency scanning covers that software layer, not the scheduler configuration itself.
Beyond the scheduler
The scheduler is one piece of a cluster. Login nodes accept SSH from users, storage systems serve shared data, and the module tree holds software many people run. Treat each as its own review item with its own owner. A well configured scheduler does not help if a login node runs an old operating system or a shared software build carries known vulnerabilities, so schedule these reviews together rather than separately.
Quick check
Why does slurmd run as root?
The admin guide says it must, because it initiates and manages user jobs.
Does the guide list the ports to open?
The quick start only shows sample port settings and says nothing about firewall rules. Check the vendor documentation and your site's network policy.
Sources
Last reviewed: 19 October 2026.
