Satellite agents get their OWN key under the infra-ops identity instead of a
copy of the fleet key, so one can be revoked by deleting a line. The list is
playbooks/files/infra-ops-satellite-keys (target short hostname + public key).
bootstrap-infra-ops-user.yaml now writes the fleet key plus that host's
satellite keys, exactly, so a re-run keeps listed keys and removes unlisted
ones. satellite-1 (SHA256:KEFUjceF...) is authorized on esh-nas only (Prime,
2026-10-13); the playbook re-run there installed both keys, and the fleet key
still logs in with sudo.
Prime's ruling 2026-10-13. esh-nas (10.0.50.50) had no infra-ops user, so key
login was refused. The same steps as bootstrap-infra-ops-user.yaml (uid/gid
850, fleet key, NOPASSWD sudoers with log_output and the BULK_DATA carve-out,
visudo-validated) ran inside the container from its host. Verified with a
direct ssh infra-ops@10.0.50.50 and sudo -n whoami = root.
docs/pfi/fleet-conventions.md § 3 pins infra-ops to 850, but the bootstrap
playbook let the OS allocate, so every host drifted (1001-2001). New
accounts now get 850 when uid and gid 850 are both free, and fall back to
OS allocation (with a note) when either is taken. The home is set to 0700
per § 1.2. Existing accounts are untouched (the step is gated on id).
Scope note: vm-esh-nas is added to the operator-granted ESH exceptions
(Prime, 2026-09-27).
Adds a host-agnostic elway play + fleet driver that stand up an
`infra-ops` system user (dedicated ed25519 key, NOPASSWD sudo with
log_output audit, docker group) so the infra-ops agent completes
DevOps work end-to-end instead of handing sudo steps back to the
operator. Scoped to PFI-owned Linux boxes; tiered (compute/app/
sensitive-infra) with SureFire/corviduo/esh/Synology explicitly
excluded. Validated live on irv-ml1.
vh