diff --git a/plans/fluid-telegram-operator-credential-lane.md b/plans/fluid-telegram-operator-credential-lane.md index 6858447..dc1605d 100644 --- a/plans/fluid-telegram-operator-credential-lane.md +++ b/plans/fluid-telegram-operator-credential-lane.md @@ -3,11 +3,11 @@ id: fluid-telegram-operator-credential-lane demand_source: fluid-telegram/workplans/FT-WP-0002 and State Hub message 287cf897-7f47-4bcc-87d6-085f43d5f03e consumer_repo: fluid-telegram credential_type: openbao-oidc-kv-read-write -status: draft +status: reviewed approved_by: null approved_at: null created: "2026-09-04" -updated: "2026-09-04" +updated: "2026-10-09" --- # Construction plan: fluid-telegram operator credential lane @@ -162,9 +162,9 @@ covering workload policy, no catalog route. `b2ed890f-a05a-4b96-95eb-2cd9d8b32caa`, key-cape `e0b5fae`). Human ID tokens always carry `groups` (LLDAP group names); `aal2` is set only after a verified privacyIDEA factor, the same pin as CCR-2026-0034. -- precondition: LLDAP group `fluid-telegram-operators`, initial member - `tegwick` only. Founder go given 2026-10-08; net-kingdom creates it (message - `259ec26d`). KeyCape does not create groups. +- precondition met: LLDAP group `fluid-telegram-operators` exists with the + single member `tegwick` (founder report 2026-10-09, created in the LLDAP admin + UI; names only). - callbacks (subset of the `openbao-admin` client registration): `http://localhost:8250/oidc/callback`, `http://127.0.0.1:8250/oidc/callback`, `http://127.0.0.1:18200/ui/vault/auth/netkingdom/oidc/callback`. Never the @@ -185,8 +185,7 @@ not added below this prefix. ## 4. Review notes (phase 2) -This section is incomplete while T01 and T02 are open; the plan must remain -`draft`. +Complete as of 2026-10-09 (T01 and T02 done); plan moved to `reviewed`. - **Reuse:** reuse the existing `netkingdom` auth mount, callback set, group claim pattern, 15-minute TTL, and KV-v2 mount. Create only the policy and @@ -196,8 +195,9 @@ This section is incomplete while T01 and T02 are open; the plan must remain access to KV metadata because the provisioner uses data GETs to detect absence; metadata evidence comes from the separately scoped builder/operator verification path. -- **Identity binding:** the group and assurance claims are confirmed; the - group's existence in LLDAP is a hard blocker, not a warning. +- **Identity binding:** group and assurance claims confirmed by key-cape; the + group exists with one member. Membership is the whole access decision, so + adding a member later is a change to this lane's reach. The role must not be readable by every OIDC user. - **Write-once semantics:** KV-v2 create/update distinction is documented, but activation also requires an owner-run non-secret probe proving the installed @@ -210,6 +210,10 @@ This section is incomplete while T01 and T02 are open; the plan must remain - **Reversal:** disable/delete the OIDC role first, then retire the policy. KV entries remain in operator custody for an explicit retention/recovery decision; teardown does not silently delete values. +- **Platform matrix:** railiance-platform's + `docs/credential-lane-designs/fluid-telegram-operator-kv.md` carries the same + four paths and capabilities as `_OPERATOR_MATRIX` in + `src/ops_mason/executor.py` (checked 2026-10-09). - **Implementation gates:** both ops-mason and railiance-platform must extend their current read-lane tooling before construction. Direct `bao policy write`/`bao write auth/netkingdom/role/...` commands outside those approved @@ -231,7 +235,38 @@ This section is incomplete while T01 and T02 are open; the plan must remain ## 5. Executive summary (phase 3) -Not yet renderable. The owner-approved tenant segment, the LLDAP group's -creation, the live structure survey, CCR/executor extension, and installed-engine create/update -probe are open inputs. When those close, this section must ask for one explicit -approval covering the exact objects and capability matrix above. +**What this creates.** One OpenBao policy and one sign-in role, nothing else: + +- policy `workload-kv-fluid-telegram-hall-of-helix-operator`: on + `platform/data/workloads/coulomb/fluid-telegram/hall-of-helix/` + `operator-app` read; `operator-session` and `bot-token` create, read, update; + `redaction-salt` create, read (write-once); plus revoke-self. No metadata, + list, parent or sibling access. +- OIDC role `fluid-telegram-hall-of-helix-workload-kv` on the existing + `auth/netkingdom` mount: only members of `fluid-telegram-operators` + (today: `tegwick`) with a verified second factor (`aal2`); 15-minute token, + 30 minutes at most; no default policy; the two loopback CLI callbacks and the + operator-tunnel UI callback. + +**Why it is safe.** The MTProto session is a full-account Telegram credential, +so the lane is attended only: a person with MFA, never an agent or the future +adapter. The path is unused and no workload policy reaches it today (live +survey 2026-10-08). ops-mason writes only the policy and role; no value passes +through it, and the salt cannot be overwritten. + +**What approval also accepts.** The tenant segment `coulomb` (replacing the +consumer's `infotech` assumption), and the exact matrix above, which +railiance-platform's lane design already matches. + +**What happens after approval.** The structure is applied through the approved +surfaces only (railiance-platform's per-path applier, RPF-WP-0035-T03, under the +attended provisioning decision `62aa95e4`; ops-mason's +`build_oidc_kv_lane`), never by direct `bao` writes. ops-warden's +`fluid-telegram-operator` entry stays non-resolvable until the seven checks +above pass, including the owner-run write-once probe. + +**Undo.** Delete the role, then the policy. Stored values stay in operator +custody until someone decides their retention explicitly. + +To approve, the founder says "APPROVE fluid-telegram-operator-credential-lane"; +ops-mason then sets `status: approved`, `approved_by` and `approved_at`. diff --git a/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md b/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md index 3f4f42b..811743c 100644 --- a/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md +++ b/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md @@ -43,9 +43,7 @@ consumer workplan `FT-WP-0002` (`f2373858-c932-5a4d-81b6-db9a3595135a`). ```task id: MASON-WP-0005-T01 -status: wait -blocked_on: human -blocking_reason: "Founder creates LLDAP group fluid-telegram-operators (member tegwick) in the LLDAP admin UI and reports names only; no agent path exists yet (net-kingdom reply a2693a9d). Live survey done 2026-10-08." +status: done priority: high state_hub_task_id: "18c9099f-882f-575c-93b9-cc68d7fbc2af" ``` @@ -101,6 +99,10 @@ net-kingdom `630ebfd`, the live image is the older `main-6c4fcaf`, and the the group in the LLDAP admin UI (Groups, Create group, add `tegwick` only) and reports names only; `tegwick` may need to sign in again before the claim shows. +2026-10-09 done: founder reports "group exists, members [tegwick]". Every T01 +input is closed (claims, callbacks, group, live survey); the plan is now +`reviewed` and its section 5 executive summary is written for T03. + ## Extend the construction and credential-change contracts ```task