SaltStack 的通讯架构模型:
Salt 采用服务端-代理的通讯模型(也可以通过 SSH 方式实现非代理模式)。服务端称为 Salt master,代理端称为 Salt minion。
Salt master 负责发送命令予 Salt minion,随后收集并展示这些命令的执行结果。一台 Salt master 可以管理几千台的系统。
SaltStack 的通讯模型
Salt master 与 minion 通讯采用的是”订阅-发布“的模式。通讯的连接由 Salt minion 发起,这意味着 minion 无须开启进向的端口(注意:此方式极大地简便了网络规则的设定)。而 Salt master 的 4505 和 4506 端口(默认)必须开启,以接收外部的连接。其中端口功能如下表所示。
端口名称 | 描述 |
Publisher (发布者) | 默认端口号 4505,所有的 Salt minion 通过此端口与 master 建立持续的连接,用于监听信息。master 通过此端口,以异步的方式发送命令至所有连接,从而让所有 minion 以近似同步地方式执行操作。 |
Request Server (请求服务器) | 默认端口号 4506,为了发送执行结果至 Salt master,Salt minion 需要通过此端口连接至请求服务器(Request Server)。同时 Salt minion 也需要通过此端口安全地请求文件以及 minion 专用的数据值(该值也被称为 Salt pillar)。此端口上,Salt master 和 minion 会建立一对一的连接。 |
通讯模型如下图所示。
Salt minion 验证机制:
(1).当 minion 启动时,其将搜索网络中的 master。当找到时, minion 将发送公钥给 Salt master,从而实现初次握手。其过程如下图所示。
(2).当初次握手后,Salt minion 的公钥将被保存在服务端,此时 master 需要使用过 salt-key 命令接收公钥(也可以采用自动机制)。注意:在 Salt minion 的公钥被接收前,Salt master 是不会将密钥发放给 minion 的,也就是说 minion 在此之前不会执行任何命令。
(3).当 Salt minion 的公钥被接收后,Salt master 就会把公钥连同用于加解密 master 信息的可变动 AES 密钥发送至 Salt minion。其中,返回给 Salt minion 的 AES 密钥由 minion 的公钥加密,可由 Salt minion 解密。
SaltStack 的安全通讯机制:
当完成验证后,Salt master 与 Salt minion 基于 AES 密钥进行加解密操作。AES 加密密钥基于最新的 TLS 版本,使用显式初始化向量和 CBC 块链接算法生成。
SaltStack 的可变动密钥:
Salt 的可变动 AES 密钥用于加密由 Salt master 发送至 Salt minion 的作业,也用于加密至 Salt master 文件服务的连接。每次 Salt master 重启或 Salt minion 解除验证后,该可变动的 AES 密钥均会自动更新。
SaltStack 的加密通讯信道:
Salt master 与 minion 间的公开通讯均以同一个可变动 AES 密钥加密。但对于 Salt master 与 minion 的直接通讯(点对点),每个会话都采用一个唯一的 AES 密钥。
例如:统一公布的作业采用可变动 AES 密钥进行加密;而以 Salt pillar 格式发送 minion 专用数据时,master 与每个 minion 都会有独立的会话,且每个会话采用唯一的 AES 密钥进行加密。
SaltStack 用户接入控制:
在命令发送至 minion 之前,Salt 将会检查发布者访问控制列表(ACL),确保接收到命令的 minion 具有正确的权限。如果权限符合,则命令将被发送至对应 minion,否则将返回报错。Salt 还可以返回将响应命令的 minion 列表,以此确定返回是否结束。
参考资料:
https://docs.saltstack.com/en/getstarted/system/communication.html