jochen
942ebe350f
Overlap as drafted in 0113 would have deleted consumer data: seven of eight providers name the resource after the login and five drop it on remove. Rotation is now undecided in 0113 and to-be 27, pending the survey. Also: a requirement naming a seat resolves to its holder, a person chooses among remaining candidates at assignment, the controller's secrets are requirements of its definition, genesis seals to the control-node key, and moving the vault or broker is break-glass.
4.4 KiB
4.4 KiB
03 — The options
Three mechanisms, weighed against 01 and 02.
A. In place, as today
The vault makes a new value. Every applier re-applies it on the same login, which all eight providers already do. Every reader is recreated by the host.
- Works with: every provider, unchanged. It is what
rotatedoes now. - Costs: a window per consumer, from the provider applying to the consumer being recreated. They are on different machines, and nothing orders them. A reader whose machine is unreachable from the mesh but still reaches its provider stays locked out until the mesh reaches it again.
- Admin credentials: the natural form. The provider module is the only party, and it has to apply the new value with the old one anyway (finding 6).
B. Two secrets on one login
The applier adds the new password beside the old one, readers move, and the old one is removed.
- Works with: redis natively, and gitea through tokens. Not with the other six, whose backends hold one password per login (finding 4).
- Verdict: not a mechanism, a special case. Using it where it exists and something else elsewhere is the "this way or that way" the design is trying to remove.
C. Two logins per consumer, over one resource
The consumer has two logins derived by the mesh, and uses one at a time. The applier creates the other with the new value and grants it the same rights over the consumer's resource. Readers move to it, and then the old login is retired, which removes the login only, never the resource.
- Works with: every backend (finding 5), after each adapter changes:
- the resource is named after the consumer, not the login. Today the two are the same string (finding 7), so existing resources keep their names, the current login stays one of the two, and only the second is new;
- both logins get the same rights, through a group role or its equivalent;
- retire a login and remove the consumer become two operations. Today they are one call, and in five providers that call destroys data (finding 3). This is the whole of the danger, and it has to be split, whatever else is chosen.
- Costs:
- seven adapters change;
- the harness learns the alternation and a confirmation per step;
- the second login's name must fit the tightest backend. That is 20 characters for a minio access key (ADR 0049), and a suffix spends part of it;
- an MQTT client identifier stays unique per connection, so mosquitto needs the client id kept apart from the login.
- Gains: no window. A reader that cannot be reached keeps a working login until it can.
- Does not apply to single-party secrets: admin credentials and a module's own secrets. There is no second party to overlap with.
Independent of the choice
- Split remove. Retiring a credential must never be able to destroy a consumer's data. That holds under A too, because A's remove is the same call. A remove that drops a database should be a separate, explicit operation, which ADR 0030 already implies: data outlives the declaration.
- Admin credentials are applied by their own provider, using the old value. That happens in place whichever mechanism consumers get. Where a backend takes the value only at first initialisation, the file alone changes nothing, and rotation needs the provider's provisioner to run the change.
- Classify the 22 readers (02) before relying on derived restarts.
Recommendation
- Consumer credentials: C, because it is the only mechanism every backend supports, and it closes the window instead of shortening it. Its prerequisite, separating the resource from the login and retiring a login from removing a consumer, is worth doing on its own, because it removes a data-loss path that exists today.
- Single-party secrets (admin credentials, a module's own): A. In place, applied by the provider that holds them.
- Until the adapters are changed, A stays as
rotateimplements it, with its window stated. It is not replaced by a mechanism the providers cannot yet carry.
This is two mechanisms, split by a property of the secret rather than by provider: whether it has one party or two. Every provider is treated the same way for the same kind of secret.