REST API 详情
Slurm 提供一个名为 slurmrestd 的 REST API 守护进程。该守护进程旨在允许客户端通过 REST API 与 Slurm 进行通信（除了命令行接口（CLI）或 C API）。
另见：
目录
无状态
Slurmrestd 是无状态的，因为它不会在请求之间缓存或保存任何状态。每个请求在一个线程中处理，然后所有状态都会被丢弃。对 slurmrestd 的任何请求与 Slurm 控制器（slurmctld 或 slurmdbd）是完全同步的，只有在 HTTP 响应代码发送到客户端后才被视为完成。Slurmrestd 在处理请求时会保持客户端连接打开。Slurm 数据库命令在每个请求结束时提交，前提是请求中的所有 API 调用成功。
强烈建议站点在 slurmrestd 和客户端之间设置缓存代理，以避免客户端重复调用查询，导致控制器的使用量高于所需（并导致锁争用）。
运行模式
Slurmrestd 当前支持两种运行模式：inet 服务模式和监听模式。
Inet 服务模式
Slurmrestd 守护进程充当一个 Inet 服务 ，将 STDIN 和 STDOUT 视为客户端。此模式允许客户端使用 inetd、xinetd 或 systemd 套接字激活服务，避免在主机上始终运行守护进程。此模式为每个客户端创建一个实例，并不支持为不同客户端重用相同实例。
监听模式
Slurmrestd 守护进程充当完整的 UNIX 服务，并持续监听新的 TCP 连接。每个连接和请求都是独立认证的。
配置
slurmrestd 可以通过环境变量或命令行参数进行配置。有关详细信息，请参见 doc/man/man1/slurmrestd.8 手册页和 REST API 快速入门指南。
插件
从 Slurm 20.11 开始，REST API 使用插件进行身份验证和内容生成。从 Slurm-21.08 开始，OpenAPI 插件可以在 slurmrestd 守护进程之外使用，其他 slurm 命令可能提供或接受最新版本的 OpenAPI 格式输出。此功能按命令提供。这些插件可以通过命令行参数选择或列出，具体说明请参见 slurmrestd 文档。
插件生命周期
OpenAPI 标准设置 "Deprecated: True" 的方法显式弃用插件。任何未标记为弃用的插件将在下一个 Slurm 主要版本中继续存在，前提是没有任何关键问题，这些问题将单独宣布。任何标记为弃用的插件将在下一个 Slurm 主要版本中删除。一般来说，最近三个插件在每个 Slurm 主要版本中保留，最旧的插件被标记为弃用。
站点始终被鼓励使用可用于代码开发的最新稳定插件版本。不同版本的同一插件之间没有兼容性保证。客户端在迁移到新版本插件时，应始终确保验证其代码。插件版本将始终包含在给定插件提供的每个方法的路径中，以确保没有两个插件提供相同的路径。
由于插件内部使用 Slurm API，因此在 Slurm 的早期版本中存在的插件应继续能够与 Slurm 的两个早期版本进行通信，类似于 Slurm 的其他组件。较新的插件可能需要 RPC 更改，这将使它们无法与早期的 Slurm 版本一起使用。例如，openapi/dbv0.0.36 插件将无法与 slurm-20.11 版本之前的任何 slurmdbd 服务器进行通信。
与 Slurm 中的所有其他插件一样，站点非常欢迎编写自己的插件，并建议通过bugzilla提交作为代码贡献。提供的插件 API 可能会在版本之间发生变化，这可能导致特定于站点的插件出现故障。
高可用性
Slurmrestd 对其在高可用集群中的部署是不可知的。该守护进程可以在多个节点上运行，但不提供与其他实例的负载均衡或故障转移协调。如果需要此功能，可以部署单独的负载均衡器。负载均衡器应能够将任何所需的身份验证信息转发到 slurmrestd 机器（请参见 安全性部分）。
slurmrestd 系统允许的连接数量也应受到限制，以便不使 slurmctld 被请求淹没。请注意 -t <线程数> 和
--max-connections <计数> 选项，slurmrestd 的节点数量，以及运行 slurmctld 的机器的规格。
安全性
Slurm REST API 的设计旨在为客户端提供必要的功能，以使用 REST 命令控制 Slurm。它不是直接面向互联网的。仅支持未加密和未压缩的 HTTP 通信。Slurmrestd 也没有防止中间人或重放攻击的保护。Slurmrestd 应仅放置在与受信任客户端通信的受信任网络中。
任何希望将 Slurm REST API 暴露于互联网或集群外的站点，至少应使用代理将所有通信包装为 TLS v1.3（或更高版本）。您还应添加监控，以拒绝任何在网络边界防火墙或 TLS 代理处反复尝试无效登录的客户端。建议通过代理进行的任何客户端过滤，以避免常见的互联网爬虫与 slurmrestd 通信，浪费系统资源，甚至导致有效客户端的延迟增加。建议站点为客户端使用短期有效的 JWT 令牌，并经常更新，可能通过非 Slurm JWT 生成器来避免强制执行 JWT 生命周期限制。还建议站点使用身份验证代理来处理所有客户端对首选单点登录（SSO）提供程序的身份验证，而不是使用 Slurm scontrol 生成的令牌。这将防止任何未经过身份验证的客户端连接到 slurmrestd。
Slurm REST API 是一个 HTTP 服务器，所有可能的网络安全预防措施都应适用于任何 Web 服务器。由于这些预防措施是特定于站点的，因此强烈建议您与站点的安全小组合作，以确保在连接到 slurmrestd 之前在代理处执行所有策略。
Slurm 尽量不在身份验证失败时给潜在攻击者任何提示。这导致客户端收到相当简短的消息：身份验证失败。当这种情况发生时，请查看相关 Slurm 守护进程（即 slurmdbd、slurmctld 或 slurmd）的日志，以获取有关实际问题的信息。
JSON Web 令牌（JWT）身份验证
slurmrestd 支持使用 JWT 来验证用户。JWT 可用于通过 REST 协议验证用户。
- 用户名头：X-SLURM-USER-NAME
- JWT 头：X-SLURM-USER-TOKEN
使用 JWT 时，重要的是在您的 slurm.conf 和 slurmdbd.conf 中为 slurmrestd 配置 AuthAltTypes=auth/jwt。
本地身份验证
slurmrestd 支持使用 UNIX 域套接字让内核验证本地用户。默认情况下，slurmrestd 不会以 root 或 SlurmUser 身份启动，或者如果用户的主组属于 root 或 SlurmUser。slurmrestd 必须位于 Munge 安全域中才能在本地身份验证模式下正常工作并与 Slurm 通信。
身份验证代理
如果使用 JWT 身份验证 不满足您的要求，站点可以选择多种身份验证系统。身份验证代理设置了一个分配给 SlurmUser 的 JWT 令牌，该令牌可以用于为集群中的任何用户代理。此能力仅允许 SlurmUser 和 root 用户，所有其他令牌仅适用于其本地分配的用户。
如果使用第三方身份验证代理，预计它将向 slurmrestd 提供正确的 HTTP 头（X-SLURM-USER-NAME 和 X-SLURM-USER-TOKEN）以及用户的请求。
Slurm 对身份验证代理没有其他要求，只需其符合 HTTP 1.1，并提供正确的 HTTP 头以允许客户端身份验证。Slurm 将明确信任提供的 HTTP 头，并且没有办法验证它们（超出代理的受信任令牌X-SLURM-USER-TOKEN）。任何身份验证代理都需要遵循您站点的安全政策，并确保代理请求来自正确的用户。这些要求是任何经过身份验证的代理的标准，并不是 Slurm 特有的。
一个工作示例可以在一个 内部工具中找到，用于测试和培训。它使用 PHP 和 NGINX 提供身份验证逻辑。 此示例仅应作为基本起点使用，因为它不适合在生产环境中部署。
最后修改于 2025 年 5 月 16 日