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.
58 lines
3.6 KiB
Markdown
58 lines
3.6 KiB
Markdown
---
|
|
status: graduated
|
|
became:
|
|
- 02-DECISIONS/0114-a-shared-credential-rotates-over-two-credentials.md
|
|
- 03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md
|
|
initiated: 2026-09-26
|
|
touches:
|
|
- 02-DECISIONS/0113-the-vault-makes-every-secret.md
|
|
- 02-DECISIONS/0049-a-consumers-identity-fits-the-tightest-backend.md
|
|
- 02-DECISIONS/0048-a-provider-creates-the-credential-the-mesh-minted.md
|
|
- 03-DESIGN/01-to-be/13-credentials-and-their-rotation.md
|
|
- 03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md
|
|
- 04-ISSUES/103-a-container-is-not-recreated-when-a-file-it-reads-changes/00-report.md
|
|
---
|
|
|
|
# 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](../../02-DECISIONS/0113-the-vault-makes-every-secret.md), 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](../../03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md),
|
|
which [ADR 0114](../../02-DECISIONS/0114-a-shared-credential-rotates-over-two-credentials.md) decided on
|
|
these findings. The identity budget in
|
|
[ADR 0049](../../02-DECISIONS/0049-a-consumers-identity-fits-the-tightest-backend.md), if a consumer
|
|
gets two logins. The rotation already implemented, which [to-be 13](../../03-DESIGN/01-to-be/13-credentials-and-their-rotation.md)
|
|
describes.
|
|
|
|
**Documents.**
|
|
|
|
- [01 — The providers](01-the-providers.md): the survey, one row per provider, and what it shows.
|
|
- [02 — The readers](02-the-readers.md): how a secret reaches a running process, and what already
|
|
recreates it.
|
|
- [03 — The options](03-the-options.md): 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.
|