Encrypting client/server communications
When the minion is first launched, it establishes a connection with the master, the address of which is specified in the minion configuration file.
The minion initiates the handshake procedure and sends its public key to the master.
After the initial connection is established, the minion's public key is stored on the master.
The master then passes its public key to the minion, along with a rotating symmetric AES key used to encrypt and decrypt messages sent by the master.
The AES key is passed encrypted with the public key previously received from the minion.
All further communications between the master and minion are encrypted with AES keys.
The rotating AES key is used to encrypt commands sent by the master to the minion and to encrypt connections to the SaltStack master's file server.
The key is regenerated each time the master is restarted, and each time a minion's key is deleted with the salt-key command.
After the key is rotated, all minions must re-authenticate to receive the updated key.
This allows the AES key to be rotated without having to interrupt the connection to the minion.
The publication data between the master and minion is encrypted with the rotating AES key.
When the master and minion interact directly, the data is encrypted with a unique AES key for each session.
The Fig. 1 shows the diagram of the mutual authentication procedure between server and minion.
The interactions shown on the diagram are described in the Table 1.
Table 1. Interactions on the diagram of the mutual authentication procedure between server and minion
| Interaction # | Description |
|---|---|
| 1 | The server generates a private and public keys |
| 2 | The minion generates a private and public keys |
| 3 | The minion sends its public key to the server every 30 seconds until the key is accepted by the server |
| 4 | If the key has not yet been accepted, the server writes it to the file <pki_dir>/master/minions_pre/<minion_id> |
| 5 | If the key has already been accepted, the server writes it to the file <pki_dir>/master/minions_denied/<minion_id> |
| 6 | The administrator receives a request to accept the key of a new minion |
| 7 | The administrator accepts the minion's key by running the command salt-key -a minion_id |
| 8 | The <minion_id> file with the minion's key is moved to the <pki_dir>/master/minions/ directory |
| 9 | The server sends its public key to the minion |
| 10 | The minion places the minion_master.pub file with the server's public key into its directory <pki_dir>/minion/ |
| 11 | The server sends the minion a symmetric AES key, which is used for encryption and decryption in the subsequent data exchange process between the server and the minion. The AES key is encrypted with the client's public RSA key |
| 12 | The administrator receives a request to accept the key of a new minion |
| 13 | The administrator rejects the minion's key |
| 14 | The <minion_id> file with the minion's key is moved to the <pki_dir>/master/minions_rejected directory |
| 15, 16 | The server rotates the AES key and distributes it to all minions (since the minion's key was rejected) |
| 17, 18, 19 | The server rotates the AES key daily and distributes it to all minions |
| 20 | Any minion was rejected or deleted |
| 21, 22, 23 | The server rotates the AES key and distributes it to all minions |