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 会建立一对一的连接。
通讯模型如下图所示。
SaltStack 的通讯及安全机制-LMLPHP

 
Salt minion 验证机制:
(1).当 minion 启动时,其将搜索网络中的 master。当找到时, minion 将发送公钥给 Salt master,从而实现初次握手。其过程如下图所示。
SaltStack 的通讯及安全机制-LMLPHP
(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
 
 
 
 
05-12 19:43