Issue 179: an adopted identity provider's admin never took the minted secret (fixed by hand through the server's bootstrap; the design question left open)

2026-10-01 11:02:18 +02:00
parent 5a6b7ca4f8
commit 79d1619f16
1 changed files with 53 additions and 0 deletions
@@ -0,0 +1,53 @@
+---
+status: resolved
+opened: 2026-10-01
+located-in: [the identity provider's assignment on the control node (an adopted database whose admin predates the mesh), mesh-catalog modules/keycloak (the minted `admin` own-secret, applied by the server only when it creates its master realm)]
+fixed-by: done by hand on 2026-10-01 through the server's own bootstrap command — the admin's password set to the value the mesh minted; no code changed
+amended-design:
+---
+
+# 179 — An adopted identity provider's admin never took the secret the mesh minted
+
+## What was observed
+
+Filed first in the forge's tracker on this repository (its issue 228, 2026-09-30). The identity
+provider's sidecar failed every call with *401 invalid_grant, Invalid user credentials*, and the
+server logged a login error for `admin-cli` every five seconds. The provisioner that creates a client
+for every consumer of `oidc-client` could never create one, so the dashboard's and the car service's
+single sign-on on the home server failed at the identity provider. Not new that day: present since
+the module moved to the mesh.
+
+## Why this is here
+
+The manifest mints an `admin` own-secret and renders it into the server's environment and the
+sidecar's file. The server reads that variable only when it creates its master realm. This instance
+was adopted with its database, whose `admin` user dates from 2022; the real password predates the
+mesh, and the minted one was inert from the first start. An own-secret the mesh mints is a statement
+the module's software is expected to honour, and adopted software that already holds its own
+credential does not — the same shape as the download client's web password on the home server
+([ADR 0092](../../02-DECISIONS/0092-an-operator-delivers-a-pair-credential.md)'s
+operator-delivered secret), met from the other side.
+
+## Resolved, 2026-10-01
+
+Reality was made to match the mesh rather than the mesh told about reality: the server's own
+bootstrap command created a temporary admin, that admin set `admin`'s password to the value the
+mesh minted — read from the sidecar's mounted secret on the machine, never printed — and the
+temporary admin was removed. Within a minute the sidecar listed realms through the console, and the
+two consumers' clients, `mesh_ace_grafana` and `mesh_ace_carhunt`, existed in the realm.
+
+The alternative, `secret accept` with the real password, was not available: the predecessor's
+configuration directory is gone and the password with it. For the next adopted module that holds a
+credential the mesh mints, the choice is the same, and the mesh's word for the second path is still
+only the download client's: a credential the mesh cannot make is the operator's to deliver.
+
+*How it was checked:* `keycloak_list_realms` through the console answers; `keycloak_list_clients`
+on the realm lists both mesh-named clients; the server's log stops the five-second login error.
+
+## Open
+
+The manifest still says the admin password is the mesh's to mint, which is true of a fresh install
+and false of an adopted one, and nothing in a definition can say which it will be. Whether an
+own-secret should be acceptable the way a pair secret is — `secret accept <node> <module> <name>`
+already exists and takes an own-secret — is a sentence for design 27's operator provider, not taken
+here.