2026-09-05 10:27:11 +00:00
1 changed files with 23 additions and 0 deletions
@@ -133,6 +133,29 @@ nothing about a disk, a mistaken command, or a service corrupting its own store.
 through the service that owns it, and only then does anything point at the new location. Never
 moved and then checked. **A backup nobody has restored is a belief, not a copy.**
 ## A module is adopted with the credentials it already has
 *2026-08-31.* **Nothing is rotated during the conversion.** A service being adopted keeps the
 password it is already using, because minting a new one is how a running service stops being able
 to reach its own database in the middle of a migration.
 The mesh has both paths and this needs the second:
 | | |
 |---|---|
 | **generate** | a new secret, sealed to both ends. What a *new* module gets |
 | **accept** | a value supplied from outside, sealed, plaintext discarded. **What an adopted module gets** |
 **Rotation is a separate act, afterwards, once everything works.** The machinery for it is built
 and proven — a credential moving at both ends with the old one ceasing to work — and it is exactly
 the sort of thing to do deliberately on a quiet afternoon rather than as a side effect of moving a
 service between systems.
 **So there is a step before any of this: read the current environment out of the old system while
 it can still be read.** Once a value is accepted, the mesh cannot show it back — *a mesh that can
 reveal a secret is a mesh that holds it* — and once the old system is gone, neither can that. A
 password nobody wrote down is a service nobody can adopt.
 ## Where it starts, and what that costs
 **On the node holding all the production data**, because that is where the services being