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