Configure individual login pods

SUNK Standard SUNK Self-Service Individual login pods give each user their own Slurm login pod. They isolate each user’s session, simplify access control, and let a directory service manage user identities centrally. Where you configure login pods depends on your SUNK version. If using version 8.0, it also depends on how you deploy:

SUNK 7.x and earlier: Configure individual login pods through the slurm-login subchart of the Slurm chart, as described on this page.
SUNK 8.0 and later
- Deployed with Helm: The slurm-login subchart no longer exists. Login configuration is part of the slurm chart, under login. login.common sets the base for both kinds of pod, login.userPods and login.groupPods override that base per kind, and each entry in login.groups picks which kinds a group gets. See Login capacity is provisioned per user and per group.
- Deployed with the SunkCluster CR: Configure login pods declaratively on the SunkCluster resource under spec.login, where userPods creates a per-user login pod for each member of a group and groupPod creates a shared per-group pod. See Create a SUNK Self-Service cluster and the SunkCluster reference.

The slurm-login parameters on this page apply to SUNK 7.x and earlier. SUNK 8.0 deleted that subchart, along with its directoryCache and its SSSD support. The sections on SSH exposure, the default shell, and conda apply to every version and deployment path.

The rest of this page shows administrators how to enable per-user Slurm login pods, integrate them with a directory service, verify the resulting resources, and avoid the access and shell pitfalls that generate the most support requests. For the slurm-login path, pass these configuration values from the values.yaml of the Slurm chart to define how slurm-login integrates and functions.

Prerequisites

Before you configure individual login pods, make sure you have:

A SUNK 7.x or earlier cluster deployed and managed through the Slurm Helm charts. SUNK 8.0 and later use the paths listed in the preceding note.
Access to edit the Slurm chart’s values.yaml, where you set the slurm-login parameters.
A directory service configured for user identities, either nsscache for SCIM or SSSD for LDAP. See manage users with nsscache and manage users with a directory service.
The user groups you want to grant access to, defined in that directory service, so you can reference them in slurm-login.directoryCache.selectGroups.
kubectl access to the cluster to verify the resulting StatefulSets and Services.

You can enable, reboot, and access individual login pods using the following capabilities:

Enable the deployment of the subchart: To enable the slurm-login capability as part of the Slurm chart, set the slurm-login.enabled parameter to true.

Reboot individual login pods: If an individual login pod is out of sync with the underlying StatefulSet, run the reboot command from within the pod. This command deletes and recreates the pod using the updated version. If the pod is out of sync, a Message of the Day (MOTD) appears at SSH login with instructions to reboot:

**********************************************************************
*                                                                    *
* The login statefulset has been updated, please restart your login  *
* pod to get the latest changes.                                     *
*                                                                    *
* To restart the login pod, issue the command "reboot".              *
**********************************************************************

Access individual login pods: For instructions on accessing each individual Slurm login pod and running Slurm jobs, refer to Connect to a Slurm login node.

Expose SSH access

You can expose login pod SSH access two ways, with a security tradeoff:

Public LoadBalancer: The login pod gets a public, internet-routable IP. This is the simplest connectivity, but it exposes SSH to internet scanning and brute-force attempts. Harden it, for example, by disabling password authentication through login.sshdConfig. Note that a NetworkPolicy doesn’t filter traffic arriving through the LoadBalancer, so it can’t be used to restrict which addresses reach the pod.
Tailscale: The login pod stays on a private overlay network with no public exposure. This is the more secure posture, at the cost of running and managing Tailscale.

Sustained scanning against a public login pod can exhaust pod resources even when every login attempt fails, so treat a private path as the stronger control and sshd hardening as defense in depth.

Set the default shell

Set the default shell through your directory service rather than chsh. A directory service provisions login pod users, not local /etc/passwd, so chsh doesn’t work. A user who wants a different interactive shell can exec it from their ~/.bashrc as a self-service workaround. The exec line must come after the interactive-shell guard. Placed before it, it hangs SCP, SFTP, rsync, and git-over-SSH, because those sessions source ~/.bashrc and then wait forever on the new shell:

# Guard first. Everything below this line runs only in interactive shells.
[[ $- != *i* ]] && return
exec zsh

Avoid conda breaking system binaries

A common support pattern: After a user activates a conda environment, system tools such as git, ssh, and curl fail with errors such as an OpenSSL version mismatch or “Could not read from remote repository.” This looks like a network or authentication problem but is a library conflict. The cause is that conda’s activation prepends conda’s lib directory to LD_LIBRARY_PATH, so system binaries load conda’s libraries instead of the system ones. conda deactivate doesn’t always clean it up. Recommend that users keep conda opt-in inside compute jobs rather than autoactivating it in ~/.bashrc on the login pod, which would break system binaries for every interactive shell. Workarounds for an affected command include installing the tool into the conda environment (conda install -n [ENV] git), or running the system binary with a cleared path (LD_LIBRARY_PATH= /usr/bin/git ...).

A shared login pod is a single memory cgroup shared by every user’s interactive processes. Heavy interactive work, such as an IDE remote-server process plus interactive Python, can OOM-kill the whole sshd tree and drop every session at once. Prefer per-user pods and direct heavy work to srun and sbatch rather than the login pod. For memory accounting and limits on compute nodes, see Diagnose unexplained memory pressure on a SUNK node.

Manage user identities and provision resources

The slurm-login.directoryCache parameter defines the directory service configuration used for managing user identities and provisioning resources. The following sections describe its key sub-values.

Select users by group

slurm-login.directoryCache.selectGroups provides a list of user groups, from which the slurm-login chart retrieves all associated users. This acts as a filter, so it includes only users that belong to one of the specified groups. It uses OR logic, so a user must be in at least one of the listed groups to be selected.

Define the polling interval

slurm-login.directoryCache.interval defines the polling interval for detecting changes to users and user groups and applying the corresponding resource updates. The value is a duration with a unit, such as 30s or 1m, and defaults to 90 seconds when unset. For more information, see directoryCache.interval in the Slurm login parameter reference.

List directory services

slurm-login.directoryCache.directoryService.directories specifies a list of directory services to configure. This is similar to the directoryService configuration in Slurm and can be duplicated or referenced using a YAML anchor for reuse.

Example nsscache configuration

The following shows a typical nsscache configuration:

slurm-login:
  enabled: true
  directoryCache:
    source: nsscache
    selectGroups: ["group1", "group2"]

See manage users with nsscache for instructions on configuring nsscache.

Example SSSD configuration

The following shows a typical SSSD configuration:

slurm-login:
  enabled: true
  directoryCache:
    source: sssd
    selectGroups: ["group1", "group2"]
    interval: 1m
    directoryService:
      # Google Secure LDAP
      directories:
        - name: google-example.com
          enabled: true
          ldapUri: ldaps://ldap.google.com:636
          user:
            canary: user@google-example.com
          defaultShell: "/bin/bash"
          fallbackHomeDir: "/home/%u"
          overrideHomeDir: /mnt/nvme/home/%u
          ldapsCert: google-ldaps-cert
          schema: rfc2307bis

For more information about configuring SSSD, see manage users with a directory service. To verify created resources, use the StatefulSets and Services as shown in the following commands.

kubectl get sts

The output is similar to the following:

NAME                             READY   AGE
slurm-login                      1/1     20d
slurm-login-slurmuser1-7fcd49e   1/1     31d
slurm-login-slurmuser2-a19c153   1/1     31d
slurm-login-slurmuser3-4fe7f1d   1/1     31d
slurm-login-slurmuser4-4f705de   1/1     31d
slurm-login-slurmuser5-5e909b3   1/1     31d

kubectl get svc

The output is similar to the following:

NAME                             TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
slurm-login                      LoadBalancer   10.96.46.53     <pending>     22:31408/TCP   35d
slurm-login-0                    LoadBalancer   10.96.146.233   <pending>     22:31276/TCP   35d
slurm-login-slurmuser1-7fcd49e   ClusterIP      10.96.61.246    <none>        22/TCP         32d
slurm-login-slurmuser2-a19c153   ClusterIP      10.96.160.110   <none>        22/TCP         32d
slurm-login-slurmuser3-4fe7f1d   ClusterIP      10.96.2.45      <none>        22/TCP         32d
slurm-login-slurmuser4-4f705de   ClusterIP      10.96.203.63    <none>        22/TCP         32d
slurm-login-slurmuser5-5e909b3   ClusterIP      10.96.184.148   <none>        22/TCP         32d

These commands confirm that the per-user StatefulSets and Services exist for each selected user. Optionally, to ensure that users only use their designated pods, you can disable the shared Slurm login StatefulSet and slurm-login Service.

Parameter reference table

The following table summarizes the slurm-login parameters described in the preceding sections for quick reference.

Parameter	Description
`slurm-login.enabled`	Set this value to `true` in the Slurm chart to enable the `slurm-login` chart.
`slurm-login.directoryCache`	Defines the directory service configuration used for managing user identities and provisioning resources.
`slurm-login.directoryCache.selectGroups`	Provides a list of user groups that the `slurm-login` chart uses to retrieve all associated users. This acts as a filter, meaning only users belonging to any of the specified groups are included. It uses OR logic, so a user must be in at least one of the listed groups to be selected.
`slurm-login.directoryCache.interval`	Defines the polling interval for detecting changes to users and user groups, as a duration such as `1m`. Defaults to 90 seconds when unset.
`slurm-login.directoryCache.directoryService.directories`	Specifies a list of directory services to configure. This is similar to the `directoryService` configuration in Slurm and can be duplicated or referenced using a YAML anchor for reuse.

For the full list of slurm-login parameters, see the Slurm login parameter reference.

​Prerequisites

​Manage individual login pods

​Expose SSH access

​Set the default shell

​Avoid conda breaking system binaries

​Manage user identities and provision resources

​Select users by group

​Define the polling interval

​List directory services

​Example nsscache configuration

​Example SSSD configuration

​Verify individual Slurm login resources

​Parameter reference table

Prerequisites

Manage individual login pods

Expose SSH access

Set the default shell

Avoid conda breaking system binaries

Manage user identities and provision resources

Select users by group

Define the polling interval

List directory services

Example nsscache configuration

Example SSSD configuration

Verify individual Slurm login resources

Parameter reference table