Agent key rotation

Every Gardience agent proves who it is to the server with its own key pair, made when the machine joined. Security > Agent key rotation replaces that key pair, on one machine now or on every machine on a schedule, so a key that was copied stops working. Admins only.

1. Go to Security > Agent key rotation and choose Edit policy (or Turn on) on the policy line under the status tiles.
2. Tick Change agent keys automatically.
3. Choose the groups of machines it covers.
4. Choose how often to change the keys (30 to 1,095 days, 365 by default).
5. Click Save policy.

Within 5 minutes, machines whose key is older than that start changing, up to 50 at a time. After that each one changes when it is due. A machine that is off changes after it reconnects.

To change one machine now, click Change key now on its row.

1. The machine makes a new 4096-bit key pair and reports the public half to the server over its current connection. The private key never leaves the machine.
2. The server's Salt master is told to accept exactly that public key for that machine. The web console cannot change keys itself: the config keeper checks the request and allows at most 200 changes an hour.
3. The machine switches to its new key and its agent restarts, which takes a few seconds. The Salt master accepts the new key only if it matches the one reported in step 1, keeps the old key for 30 days, and starts a new session key, so anything still holding the old key is cut off.
4. Gardience checks that the machine answers with its new key, and the change is done.

The restart waits until no package manager and no other Gardience job is running on the machine (up to 30 minutes).

If the machine does not answer with its new key within 15 minutes, it puts its old key back on its own and the Salt master lets it in again. The machine is never left unable to reach the server. Its row shows Went back to old key, and the policy tries again after 6 hours.

The old key can come back only during those 30 minutes, only until Gardience confirms the new key, and only once the machine has stopped answering on its new key for two minutes (1.28.1). That last condition is what tells the machine's own rollback from an outsider: a helper that rolled back restarted the agent on the old key, so nothing answers on the new one; someone else who copied the old key presents it while the machine is still up on its new key. In that case the new key stays, the old key stays refused, the audit log records agentkey.old_key_presented, and the notification channel is told. After a change is confirmed or the window closes, the old key is watched for 30 days and reported the same way if it appears again, at most once an hour per machine.

Change key now answers with the machines that really started and, for the others, why they wait: a change already under way, not connected, or more than 50 at a time.

Every start, change, failure, rollback, and refused old key is in the audit log (agentkey.rotate_started, agentkey.rotated, agentkey.failed, agentkey.rolled_back, agentkey.old_key_presented), along with policy changes (agentkey.policy).

• Linux agents need systemd. Windows agents use a scheduled task.
• The machine must have received Gardience's agent modules. They sync at the first scan after it joins.
• Attach mode: when Gardience is attached to your own Salt master, that master holds the agent keys, so key changes are made there, not in Gardience.

• Local admin passwords
• Security model