jochen
e387c4bd0e
The fact-check found mailu, whose user is its mailbox, so 0114 rotates over two credentials rather than two logins, the adapter choosing what a credential is. Also: minio keeps non-empty buckets; five backends take their admin credential only at first init, so single-party rotation is staged; postgres ownership moves to a non-login role; the harness keys by consumer; rotation state lives with the vault. Consistency fixes across 0110-0113, 26 and 27; issue 103 resolved by mesh-host PR #22.
3.6 KiB
status, became, initiated, touches
| status | became | initiated | touches | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| graduated |
|
2026-09-26 |
|
016 — How a credential can be rotated
What. Which rotation mechanisms the mesh's providers can actually support, measured against their code rather than assumed. Every provider in the catalogue was read, found by listing every definition that provides something: how it names what it makes for a consumer, what its remove destroys, whether it re-applies a password, whether its backend can hold two secrets for one login or two logins on one resource, and how its own administrative credential is set. The consumer side was read too: when a module reads a secret, and what makes it read a new one.
Why. ADR 0113, as first drafted, chose overlap: add a second login beside the first, move every reader, then remove the old one, "through the adapter's existing create and remove", with "no consumer changes". A review showed that claim false. In most providers the consumer's data is named after its login, and remove drops the data with the login. Overlap as written would have deleted every consumer's database on its first rotation. The mechanism has to be chosen on what the providers do.
What it touches. Rotation in 0113 and to-be 27, which ADR 0114 decided on these findings. The identity budget in ADR 0049, if a consumer gets two logins. The rotation already implemented, which to-be 13 describes.
Documents.
- 01 — The providers: the survey, one row per provider, and what it shows.
- 02 — The readers: how a secret reaches a running process, and what already recreates it.
- 03 — The options: each rotation mechanism against those facts, and a recommendation.
Finding, in one paragraph. All nine credential providers already re-apply a consumer's password
in place on every create, and the controller's rotate command relies on that. It is a working
rotation with a stated window. Eight of the nine name the consumer's resource after its login, and five
destroy the consumer's data when they remove the login. The harness, keyed by login, would do the same
on any change of login. Only one backend holds two passwords on one login, and two more hold several
tokens. Eight backends can grant two logins the same rights over one resource; the ninth can give one
login a second token. So every provider can hold two credentials over one resource, but only after
each adapter separates the consumer's resource from the credential that reaches it. In postgres
that also means the resource belongs to a role no login owns. Administrative credentials are a
different case. They have one party and a fixed name, and five backends take them only at first
initialisation, so changing one needs the old and the new value at once.