ops-mason/workplans/MASON-WP-0009-keycape-secrets-engine-openbao-client-custody.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	state_hub_workstream_id
MASON-WP-0009	workplan	Place the KeyCape secrets-engine-openbao client secret in OpenBao	infotech	ops-mason	blocked	planning	claude	netkingdom	2026-10-06	2026-10-07	d9be08f5-a0f5-5cd1-8f87-0a6868661d77

MASON-WP-0009 — Place the KeyCape secrets-engine-openbao client secret in OpenBao

Goal

Founder direction 2026-10-06: the client secret lives in OpenBao and ops-mason decides where and how. Plan: plans/keycape-secrets-engine-openbao-client-custody.md (status: reviewed). Location platform/workloads/keycape/secrets-engine-openbao field CLIENT_SECRET (KV v2, cas_required, max_versions=2). Issuer reads it through the existing sso-only ESO/Kubernetes reader. secrets-engine reads it in memory per command through a new attended operator OIDC role (5m, 4 uses, revoke-self). There is no consumer copy at rest. The design supersedes secrets-engine D1–D4.

Boundaries

• ops-mason designs, reviews and verifies (capabilities only) and proposes the pointer-only route. It builds nothing here (no OIDC writer; MASON-IN-0004).
• railiance-platform applies all objects and owns generation/write via its CCR.
• secrets-engine owns the in-memory provider. KeyCape/NetKingdom own the registration, the claim and the restart.
• No value enters Git, State Hub, logs or agent context.

Design and review the lane

id: MASON-WP-0009-T01
status: done
priority: high
state_hub_task_id: "67e6b80b-3d21-5d19-80e9-23afb2453d0a"

Plan written and reviewed from source state. The live bao survey is deferred to T04 (no bao access in this task).

Founder approval

id: MASON-WP-0009-T02
status: wait
blocked_on: founder-approval
blocking_reason: "Founder must give A1 (this plan), A2 (revised CCR-2026-0033 with the operator reader and confirmed bound claims) and A3 (custody-child decision id); see plan section 5."
priority: high
state_hub_task_id: "4329bcd1-d42f-56a3-92cb-63b36d79549e"

Owner changes delivered

id: MASON-WP-0009-T03
status: wait
blocked_on: message-from:railiance-platform
blocking_reason: "railiance-platform revises CCR-2026-0033 and its custody child; secrets-engine replaces the file provider for this profile; key-cape confirms the groups claim and MFA assurance for the OpenBao OIDC client."
priority: high
state_hub_task_id: "f59fae58-397a-5bf5-9d1d-a33dc4aaa2ac"

Verify and propose the route

id: MASON-WP-0009-T04
status: done
priority: medium
state_hub_task_id: "01f55a4d-06de-5d48-a3db-a0746dcf9892"

After platform applies the objects: a live metadata-only survey and the plan's six verification checks (capabilities and metadata only). Then a pointer-only ops-warden entry for the operator lane (resolvable: false until the checks pass).

Note (2026-10-07, MASON-IN-0004): the capability verification runs under the read-only ops-mason-survey grant, which replaces ops-mason-build. Installing that policy is a founder act (AGENTS.md, "Installing the survey policy"); ops-mason cannot install or widen it.

Done 2026-10-07 under grant claude-MASON-WP-0009-T04 (ops-mason-survey, revoked and shredded after use). Evidence, value-free: docs/evidence/2026-10-07-keycape-secrets-engine-openbao-capabilities.json. All five capability checks pass: both lane policies match the platform repo files; both roles match CCR-2026-0033/0034 (retired redirect noted); KV metadata is v1, cas_required, max_versions=2, delete_version_after=0s, custom metadata as in plan 3.1; only the two lane policies plus platform-admin/root reach the data path, no auth/jwt (or keycape-services) mount exists, the ESO reader is on Kubernetes auth; the grant itself is deny on the data path and read-only on sys/policies/acl/*. Not permitted by the survey grant: auth/keycape/role. Owner observations (retired ops-mason-build still installed; secrets-engine-prod can author se-prod-* policies; this path is missing from agent-high-risk-boundary) are in the evidence file. Plan checks 1-3 and 6 need live lane tokens and the route proposal is still owed: T05.

Side finding, fixed: scripts/bao-session.sh grant reported "policy does not exist yet" whenever bao policy read failed, including when the founder's ~/.vault-token session was expired or unauthorised. It now says "cannot read (session expired or not permitted)" unless bao answers "No policy named" (tests/test_bao_session.py).

Live lane proof and pointer route

id: MASON-WP-0009-T05
status: wait
blocked_on: message-from:railiance-platform
blocking_reason: "Plan section 4 checks 1-3 and 6 need live lane tokens and the secrets-engine-openbao service-JWT mount and policy (RPF-WP-0035-T02), which are not applied yet; then recheck invariant (ii) and propose the pointer-only ops-warden route."
priority: medium
state_hub_task_id: "1b1a0566-add7-59c1-94b0-6bb81d2d1537"

Once the service-JWT lane exists: re-run invariant (ii) against its policy, collect owner-run evidence for checks 1-3 and 6 (operator and ESO token capabilities, non-member refusal, a secrets-engine service-jwt run), then propose the pointer-only ops-warden entry for the operator lane (resolvable: false until those pass).