Rotation lifecycle: verify host-key blast radius (consumer completeness + post-activate provisioning check) #9

New issue

Open

opened 2026-07-15 15:20:50 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-07-15 15:20:50 +01:00

User story: So that I can trust a completed host identity rotation, the workflow must enumerate every consumer and verify that provisioning still works before stale consumers are discovered later.

Part of the "Host-key rotation lifecycle & safety" arc.

Context

nexus-host-key's consumer set is implicit: it re-keys the consumers it hardcodes (agenix secrets, VM authorized_keys, the Forgejo identity checks) and silently omits others. activate verifies VM SSH reachability, Forgejo auth, and agenix decrypt with the new key — but nothing verifies that provisioning, the highest-stakes consumer of the host key, still works. So a rotation can report success while leaving the fleet unprovisionable, and the failure only surfaces the next time someone runs provision-vm-from-host. (The installer ISO is one such omitted consumer — see the sibling issue.)

The high-level gap

Host-key rotation has no blast-radius verification. Two consequences:

New consumers of ~/.ssh/host fall out of rotation silently.
A rotation that leaves a consumer stale is caught long after, at provision time, far from the cause.

Ask

Enumerate the consumers of ~/.ssh/host as an explicit, reviewed set — agenix-encrypted secrets, VM authorized_keys, known_hosts_vms, the Forgejo SSH identity, and the installer ISO — so adding a new consumer forces a conscious update to the rotation path instead of a silent omission.
Add a post-activate end-to-end check that a provision would succeed with the new key. Cheapest form: assert the installer ISO authorizes the current secrets.lib.identity.hostPublicKeys. Most thorough: a provision smoke test against a throwaway VM. Fail the rotation loudly if a consumer is stale.

Notes

Distinct from the general hardening of forge-ssh-key / vm-ssh-host-key — this is about nexus-host-key's own consumer completeness and end-to-end verification. The consumer list and smoke test reference deployment values (ISO path, deploy flake, VM names) supplied by operator config.

**User story:** So that I can trust a completed host identity rotation, the workflow must enumerate every consumer and verify that provisioning still works before stale consumers are discovered later. _Part of the "Host-key rotation lifecycle & safety" arc._ --- ## Context `nexus-host-key`'s consumer set is **implicit**: it re-keys the consumers it hardcodes (agenix secrets, VM `authorized_keys`, the Forgejo identity checks) and silently omits others. `activate` verifies VM SSH reachability, Forgejo auth, and agenix decrypt with the new key — but nothing verifies that **provisioning**, the highest-stakes consumer of the host key, still works. So a rotation can report success while leaving the fleet unprovisionable, and the failure only surfaces the next time someone runs `provision-vm-from-host`. (The installer ISO is one such omitted consumer — see the sibling issue.) ## The high-level gap Host-key rotation has no blast-radius verification. Two consequences: 1. New consumers of `~/.ssh/host` fall out of rotation silently. 2. A rotation that leaves a consumer stale is caught long after, at provision time, far from the cause. ## Ask 1. **Enumerate the consumers of `~/.ssh/host` as an explicit, reviewed set** — agenix-encrypted secrets, VM `authorized_keys`, `known_hosts_vms`, the Forgejo SSH identity, and the installer ISO — so adding a new consumer forces a conscious update to the rotation path instead of a silent omission. 2. **Add a post-`activate` end-to-end check that a provision would succeed with the new key.** Cheapest form: assert the installer ISO authorizes the current `secrets.lib.identity.hostPublicKeys`. Most thorough: a provision smoke test against a throwaway VM. Fail the rotation loudly if a consumer is stale. ## Notes Distinct from the general hardening of `forge-ssh-key` / `vm-ssh-host-key` — this is about `nexus-host-key`'s own consumer completeness and end-to-end verification. The consumer list and smoke test reference deployment values (ISO path, deploy flake, VM names) supplied by operator config.