认证插件

概述

了解Slurm接收到的远程过程调用（RPCs）来自可信来源是很重要的。Slurm提供了几种不同的认证机制来验证请求的合法性和完整性。

MUNGE

MUNGE可以用于创建和验证凭据。它允许Slurm认证来自其他主机的请求的UID和GID，这些主机具有匹配的用户和组。在构建Slurm时必须存在MUNGE库，以便它能够使用munge进行认证。集群中的所有主机必须共享一个加密密钥。

设置

MUNGE要求在运行slurmctld、slurmdbd和节点的机器上有一个共享密钥。您可以通过输入自己的文本或生成随机数据来创建密钥文件：
```
dd if=/dev/random of=/etc/munge/munge.key bs=1024 count=1
```
此密钥应由“munge”用户拥有，且不应被其他用户读取或写入：
```
chown munge:munge /etc/munge/munge.key
chmod 400 /etc/munge/munge.key
```
将密钥文件分发到集群上的机器。它需要在运行slurmctld、slurmdbd、slurmd和任何您配置的提交主机的机器上。使用您选择的分发方法。
需要使用认证的机器上应运行“munge”服务。它应在所有您分发了密钥的机器上启用并启动：
```
systemctl enable munge
systemctl start munge
```
更改认证机制需要重启Slurm守护进程。在更新slurm.conf之前需要停止守护进程，以便客户端命令不使用运行的守护进程所期望的机制以外的其他机制。
更新您的slurm.conf和slurmdbd.conf以使用MUNGE认证。
- slurm.conf:
```
AuthType = auth/munge
CredType = cred/munge
```
- slurmdbd.conf:
```
AuthType = auth/munge
```
使用适合您集群的方法重新启动Slurm守护进程。

Slurm

从版本23.11开始，Slurm有自己的插件，可以创建和验证凭据。它验证请求来自具有匹配用户和组的其他主机上的合法UID和GID。集群中的所有主机必须共享一个加密密钥。

单密钥设置

为了正确进行认证，您必须在运行slurmctld、slurmdbd和节点的机器上有一个共享密钥。您可以通过输入自己的文本或生成随机数据来创建密钥文件：
```
dd if=/dev/random of=/etc/slurm/slurm.key bs=1024 count=1
```
slurm.key或slurm.jwks应由SlurmUser拥有，且不应被其他用户读取或写入。此示例假设SlurmUser是“slurm”：
```
chown slurm:slurm /etc/slurm/slurm.key
chmod 600 /etc/slurm/slurm.key
```
将密钥文件分发到集群上的机器。它需要在运行slurmctld、slurmdbd、slurmd和sackd的机器上。
更新您的slurm.conf和slurmdbd.conf以使用Slurm认证类型。
- slurm.conf:
```
AuthType = auth/slurm
CredType = cred/slurm
```
- slurmdbd.conf:
```
AuthType = auth/slurm
```
使用适合您集群的方法重新启动守护进程。

从版本24.05开始，您可以选择创建一个包含多个密钥定义的slurm.jwks文件。slurm.jwks文件有助于密钥轮换，因为在轮换密钥时无需同时重启集群。相反，scontrol reconfigure就足够了。使用slurm.jwks文件不需要任何slurm.conf参数，而是通过slurm.jwks文件的存在启用此功能。如果slurm.jwks不存在或无法读取，集群将默认为slurm.key。

多密钥设置

多密钥设置与单密钥设置非常相似，只是密钥文件更丰富。密钥文件由一个jwks风格的“keys”列表组成，其中包含多个“key”条目。密钥条目有许多不同的字段。下面是一个示例文件。

{
  "keys": [
    {
      "alg": "HS256",
      "kty": "oct",
      "kid": "key-identifier",
      "k": "VGhlIGtleSBiZWxvdyBtZSBuZXZlciBsaWVz",
      "exp": 1718200800
    },
    {
      "alg": "HS256",
      "kty": "oct",
      "kid": "key-identifier-2",
      "k": "VGhlIGtleSBhYm92ZSBtZSBhbHdheXMgbGllcw==",
      "use": "default"
    }
  ]
}

以下字段由auth/slurm使用。（可以存在其他字段，但会被忽略。）

alg — 使用该密钥的加密算法。此字段是必需的，值必须是HS256。
kty — 用于签署密钥的加密算法家族。此字段是必需的，值必须是oct。
kid — 用于密钥匹配的区分大小写的文本标识符。此字段是必需的，文本必须是唯一的。
k — 实际密钥，以Base64或Base64url编码的二进制块表示。此字段是必需的，必须长于16字节。
use — 确定此密钥是否为默认密钥。可接受的值只有“default”，表示此密钥为默认密钥。只能有一个默认密钥。此字段是可选的。
exp — 密钥的到期日期，以Unix时间戳表示。此字段是可选的。

一旦创建了slurm.jwks文件，使用与单密钥设置相同的过程来设置auth/slurm，只是使用slurm.jwks文件而不是slurm.key文件。

如果集群无法从LDAP或操作系统访问一致的用户ID，您可以使用 use_client_ids选项允许其使用Slurm认证机制。

SACK

Slurm的内部认证利用了一个子系统 — Slurm Auth 和 Cred Kiosk (SACK) — 负责处理来自auth/slurm和cred/slurm插件的请求。此子系统由slurmctld、slurmdbd和slurmd守护进程在每个系统上自动启动和内部管理，无需运行单独的守护进程。

对于不运行这些Slurm守护进程的登录节点，应运行sackd守护进程，以允许Slurm客户端命令认证到集群的其他部分。此守护进程还可以管理无配置环境的缓存配置文件。

从版本25.05开始，可以通过更改单独的systemd服务文件中的RuntimeDirectory选项，使多个sackd守护进程在同一登录节点上共存。客户端可以通过管理SLURM_CONF环境变量以指向不同的集群配置文件来认证不同的sackd守护进程。有关更多信息，请参阅 sackd(8)手册。

JWT

Slurm可以配置为使用JSON Web Tokens (JWT)进行认证。这是通过AuthAltType参数配置的，仅用于客户端到服务器的通信。您可以在此处阅读有关此认证机制及其安装的更多信息。

最后修改于2025年4月23日