Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0e75a-fc5c-7913-9dba-9846210c766d
130 lines
4.7 KiB
Markdown
130 lines
4.7 KiB
Markdown
---
|
||
id: MASON-WP-0004
|
||
type: workplan
|
||
title: "Describe every stored credential so the store is navigable"
|
||
domain: infotech
|
||
repo: ops-mason
|
||
status: blocked
|
||
flavor: planning
|
||
owner: codex
|
||
topic_slug: custodian
|
||
created: "2026-08-28"
|
||
updated: "2026-09-28"
|
||
related:
|
||
- MASON-WP-0003
|
||
- NK-WP-0033
|
||
state_hub_workstream_id: "e5656747-a974-581a-a3d4-4e6bb7262f4c"
|
||
---
|
||
|
||
# Describe every stored credential so the store is navigable
|
||
|
||
## Goal
|
||
|
||
Give all 21 credential paths in `operators/` and `platform/workloads/` the five
|
||
`custom_metadata` fields the custody standard requires, so an operator can find
|
||
out what a credential is without reading it.
|
||
|
||
## Why this exists
|
||
|
||
`custody-inventory.py` reported 21 paths on 2026-08-28. Four carry descriptions
|
||
— the ones `MASON-WP-0003` touched. **Seventeen carry none.**
|
||
|
||
An undescribed credential is one nobody can identify without reading it, which
|
||
means orientation requires the very access the store exists to control. It also
|
||
means the two failure modes of the previous week stay available: no `used_by`
|
||
list, so a rotation misses a consumer the way privacyIDEA's resolver was missed
|
||
for four days; and no `on_loss` line, so recovery gets improvised under pressure
|
||
the way the LLDAP predecessor's did.
|
||
|
||
This is not urgent the way a broken login is urgent. It is the difference
|
||
between a secret store and a drawer of unmarked keys.
|
||
|
||
## What "described" means
|
||
|
||
Five fields, per `net-kingdom/docs/platform-root-custody.md`: `description`,
|
||
`owner`, `used_by`, `rotation`, `on_loss`. Metadata only — no path's value is
|
||
read, and `ops-mason-build` cannot read one.
|
||
|
||
## Establish owners before writing anything
|
||
|
||
```task
|
||
id: MASON-WP-0004-T01
|
||
status: wait
|
||
priority: medium
|
||
state_hub_task_id: "5bda75f2-f780-579e-9d44-cc4011662b9a"
|
||
```
|
||
|
||
Most of the seventeen predate this repository and ops-mason cannot invent what
|
||
they are for. Group them by mount prefix, propose an owning repo for each from
|
||
the ops-warden catalog and the paths themselves, and take the founder's ruling
|
||
on the ones that are genuinely unclear.
|
||
|
||
Guessing is the failure mode to avoid: a confidently wrong `used_by` is worse
|
||
than an empty one, because a rotation will trust it.
|
||
|
||
Acceptance: every one of the seventeen has a named owner, or is explicitly
|
||
listed as unknown with the question that would settle it.
|
||
|
||
## Describe the paths whose purpose is already documented
|
||
|
||
```task
|
||
id: MASON-WP-0004-T02
|
||
status: wait
|
||
priority: medium
|
||
state_hub_task_id: "a6a944d7-21c5-5043-a78d-b3809de0ee64"
|
||
```
|
||
|
||
Several are covered by an existing ops-warden catalog entry, playbook, or
|
||
construction plan in `plans/` — `railiance/backup/*`, `rapp-qonto/*`,
|
||
`user-engine/runtime`, `reuse-surface/runtime-secrets` among them. For those the
|
||
five fields can be written from documents that already exist, with `rotation`
|
||
pointing at the real procedure rather than paraphrasing it.
|
||
|
||
Acceptance: `custody-inventory.py` reports these paths without a `!`, and each
|
||
`rotation` field names a document that exists.
|
||
|
||
## Resolve the rest with their owners
|
||
|
||
```task
|
||
id: MASON-WP-0004-T03
|
||
status: wait
|
||
priority: low
|
||
state_hub_task_id: "fff26914-d854-5854-b350-d7241812fb04"
|
||
```
|
||
|
||
Blocked on T01. What remains after T02 are paths whose purpose is not written
|
||
down anywhere. Each needs its owner to answer three questions: what is this, what
|
||
breaks when it changes, and what do you do when it is lost.
|
||
|
||
A path whose owner cannot answer the third question is a finding in its own
|
||
right — it is a credential with no recovery story, and that is worth knowing
|
||
before it is lost rather than after.
|
||
|
||
Acceptance: `custody-inventory.py` exits 0 across both mounts, or the remainder
|
||
is a short list with a recorded reason each.
|
||
|
||
## Make an undescribed path visible before it accumulates
|
||
|
||
```task
|
||
id: MASON-WP-0004-T04
|
||
status: wait
|
||
priority: low
|
||
state_hub_task_id: "9a0cea06-eb63-54ad-963d-db4ea79c7c66"
|
||
```
|
||
|
||
Blocked on T03. Seventeen accumulated because nothing ever looked. Wire
|
||
`custody-inventory.py --undescribed` into whatever already runs regularly
|
||
against this repo, so a new undescribed path is noticed in days rather than
|
||
discovered in a year.
|
||
|
||
The check must not fail a build for a path someone else owns; it reports, and
|
||
the report has a reader.
|
||
|
||
Acceptance: an undescribed path added today surfaces without anyone
|
||
remembering to look.
|
||
|
||
## Loose-end review — 2026-09-28
|
||
|
||
T01–T04 remain wait: no valid scoped metadata grant/current inventory or complete owner/recovery confirmations are available. Inventory failure handling and the private-tunnel defaults are fixed and tested; scheduled reporting still needs its reader and credential.
|
||
|
||
Evidence and precise resumption conditions: [review](../docs/evidence/2026-09-28-loose-end-review.md). Existing tasks retain all remaining obligations; no new task or workplan was opened.
|