jochen
43f63ed41c
Graduates research 016. Retiring a login is separated from removing a consumer, which closes a data-loss path in five providers; single-party secrets rotate in place; the number of parties decides, not the provider.
55 lines
3.2 KiB
Markdown
55 lines
3.2 KiB
Markdown
---
|
|
status: graduated
|
|
became:
|
|
- 02-DECISIONS/0114-a-shared-credential-rotates-over-two-logins.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: 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 both mark it undecided and point here. 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 eight 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. Seven of the eight name the consumer's resource after its login,
|
|
and five drop the resource when they remove the login, so a second login is impossible without
|
|
changing the adapter. Only one backend holds two passwords on one login. But every backend can grant
|
|
two logins the same rights over one resource. So overlap is possible everywhere, but only after each
|
|
adapter separates *the consumer's resource* from *the login that reaches it*. Administrative
|
|
credentials are a different case. They have one party, a fixed name, and in three providers they are
|
|
taken only at first initialisation.
|