022 — a credential belongs to a node, so a second consumer refuses

Found while checking whether the module vocabulary covers real use cases. A node running three modules that all want a database cannot be planned at all: anchor has 3 modules asking for "postgres-database" and they would share one credential: gitea, keycloak, umami The refusal is right about what it says and wrong about what it implies. They would share one credential, and sharing is worse than refusing — but the arrangement being refused is the ordinary one, and the node this mesh exists to take over runs eight modules against one database server. The cause is the key: a credential is keyed by provision, consumer node and provider node, so `consumer` is a machine. The provisioner inherits it and names the role `mesh_<node>`. The refusal is not a check that caught something; it is the only honest thing that function can do with a key that cannot tell two consumers apart. It is the same mistake as 021 with a different face. There the machine was treated as a trust boundary; here it is treated as an identity, as though "who is asking" is answered by naming a host. Two modules on one node are as separate as two on different nodes. Worth stating plainly: without the refusal, gitea's login would have opened keycloak's database, and nothing would have said so — from the provisioner's side it created exactly what it was asked to create. Not a local fix. It crosses the control plane, the grant file naming and every provisioner that names something after a consumer.
2026-09-01 02:28:39 +02:00
parent 36d342f176
commit c86adbe3cc
1 changed files with 81 additions and 0 deletions
@@ -0,0 +1,81 @@
 ---
 status: located
 opened: 2026-09-01
 located-in: [mesh-control]
 fixed-by:
 amended-design:
 ---
 # 022 — A credential belongs to a node and a provision, so a second consumer refuses
 ## Symptom
 A node running more than one module that wants the same provision **cannot be planned at all**:
 ```
 anchor has 3 modules asking for "postgres-database" and they would share one
 credential: gitea, keycloak, umami
 ```
 The refusal is correct about what it says. They *would* share one credential, and sharing one is
 worse than refusing — a login that opens three databases is not three credentials. But the
 arrangement being refused is the ordinary one. **The node this mesh exists to take over runs
 eight modules against one database server.**
 ## Where it comes from
 A credential is keyed by *(provision, consumer node, provider node)*:
 ```go
 func (i *Inventory) SecretFor(ctx context.Context, name, consumer, provider string) (Secret, error)
 ```
 `consumer` is a **node**. Everything downstream inherits that granularity: `Grant.Consumer` is a
 node, the grant's file is named after a node, and the provisioner names the role it creates after
 one — `role := mark + c.Node`.
 So the refusal in `ContributionsTo` is not a check that found a problem. It is the only honest
 thing that function can do, given a key that cannot tell two consumers apart.
 ## Why it was not noticed
 **Every scenario so far had one consumer per node.** That is the natural shape of a small test —
 a consumer here, a provider there — and it is the shape of every lab scenario written to date. A
 node with two modules wanting a database is not an edge case discovered by fuzzing; it is what a
 real machine looks like, and nothing had modelled a real machine yet.
 The refusal also reads as deliberate. It names the modules, explains the consequence, and refuses
 rather than picking — the house rule everywhere else. It looks like a decision. It is a limit.
 ## Why the granularity is wrong
 The same argument that closed [`021`](../021-a-consumer-on-the-providers-machine-is-given-no-credential/00-report.md).
 There, the machine was treated as a trust boundary and containers made that untrue. Here, the
 machine is treated as an *identity* — as though "who is asking" is answered by naming a host.
 **Two modules on one node are as separate as two on different nodes.** They run as different
 containers, on different networks, with different data. A key that cannot distinguish them means
 the mesh cannot express the thing it is for.
 It also silently weakens what the provisioner does. `mesh_<node>` is one role. Had the refusal not
 been there, gitea's login would have opened keycloak's database — and nothing anywhere would have
 said so, because from the provisioner's side it created exactly what it was asked to create.
 ## What a fix has to keep
 - **The refusal, where it is still right.** Two modules wanting one provision must not silently
  share a credential. After a fix they do not share one, so there is nothing to refuse — but a
  genuine collision must still refuse rather than pick.
 - **A credential per consuming module**, sealed to the node that holds it. Both facts are needed:
  the module is who it is for, the node is what it is sealed to.
 - **The provisioner names what it creates after the module**, so a login is traceable to the thing
  using it, and so withdrawing one consumer does not remove another's.
 - **Withdrawal still works.** A module unassigned must lose its login while the others keep theirs
  — which is precisely what one role per node cannot do.
 - **Existing single-consumer nodes keep working**, since that is every scenario that exists.
 ## Scope
 This crosses the control plane, the grant file naming, and every provisioner that names something
 after `Consumer`. It is not a local fix, and it is the last thing between the current state and a
 node that looks like a real one.