feat(mason): build the state-hub forge read lane (MASON-WP-0003-T02)

Policy workload-kv-read-state-hub-forge-derivation and Kubernetes auth
role state-hub-forge-derivation, verified both directions through a
2-minute test token that was revoked after use: read on its own path;
deny on forgejo-admin, on the shared llm-connect provider secrets, and
on the parent metadata path.

Kubernetes auth replaces the approved AppRole. The plan's §2 survey was
written from disk with no OpenBao session and could not see that
kubernetes/ auth is enabled on this cluster; the plan's own phase-4
instruction to re-verify against live state is what surfaced it. Ruled
by the founder at phase 4. No static credential is created, so nothing
has to be delivered into the cluster or rotated.

The live survey also re-checked reuse: workload-kv-read-agent-harness-
forgejo grants one repository deploy key, not organisation-wide read, so
§2's rejection of reuse stands.

ops-mason handled no secret value. The KV path does not exist until
paste_once_provision writes the token.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
This commit is contained in:
tegwick 2026-08-27 22:49:13 +02:00
parent fb90abdfcb
commit 84c36a6c26
2 changed files with 80 additions and 2 deletions

View file

@ -119,7 +119,7 @@ ruled on; build-phase posture stands as proposed. Reasoning in
```task
id: MASON-WP-0003-T02
status: todo
status: done
priority: high
state_hub_task_id: "68a1c8e4-c12b-550e-962c-06a90ab8c1c2"
```
@ -140,6 +140,22 @@ delivered a working token into it, confirmed by the consumer rather than by
reading the value here. Recorded in `audit/build-log.jsonl` against the
approved plan.
**Done (2026-08-27).** Policy `workload-kv-read-state-hub-forge-derivation` and
Kubernetes auth role `state-hub-forge-derivation` created and verified; see
`plans/state-hub-forge-derivation-read.md` §7 and `audit/build-log.jsonl`.
**Kubernetes auth replaces the approved AppRole**, ruled at phase 4 after the
live survey found `kubernetes/` auth enabled on this cluster — something §2's
disk-only survey could not see. No static `role_id`/`secret_id` is created, so
there is nothing to deliver or rotate.
ops-mason handled no secret value. The KV path does not exist yet and will not
until `paste_once_provision` writes the token; the policy grants read on it
either way. Two prerequisites remain before the lane carries traffic, both
outside this repo: ServiceAccount `state-hub/state-hub`
(`STATE-WP-0084-T02` — the role deliberately does not bind to `default`), and
the minted token.
## Register the lane in the routing catalog
```task