coulomb/ops-mason
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

MASON-WP-0009: plan OpenBao custody for the KeyCape secrets-engine-openbao client secret

Browse source 
Founder direction 2026-10-06: the secret lives in OpenBao. The plan confirms
platform/workloads/keycape/secrets-engine-openbao:CLIENT_SECRET (KV v2,
cas_required, max_versions=2) and keeps the sso-only ESO issuer reader. It
replaces the workstation consumer file with an attended operator OIDC reader
(5m, 4 uses, revoke-self, value in memory only) and records why the
dependency graph is acyclic. Status: reviewed, awaiting founder approvals A1-A3.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 132360@bnt-lap001
Assistant-Session: 769b1afd-4330-4c86-96b2-e510e26db42b
This commit is contained in:
tegwick 2026-10-06 14:02:11 +02:00
parent 7e86430913
commit 658cdbc206
2 changed files with 347 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

79
workplans/MASON-WP-0009-keycape-secrets-engine-openbao-client-custody.md Normal file
View file

@ -0,0 +1,79 @@
---
id: MASON-WP-0009
type: workplan
title: "Place the KeyCape secrets-engine-openbao client secret in OpenBao"
domain: infotech
repo: ops-mason
status: blocked
flavor: planning
owner: claude
topic_slug: netkingdom
created: "2026-10-06"
updated: "2026-10-06"
---
# 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
```task
id: MASON-WP-0009-T01
status: done
priority: high
```
Plan written and reviewed from source state. The live `bao` survey is
deferred to T04 (no bao access in this task).
## Founder approval
```task
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
```
## Owner changes delivered
```task
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
```
## Verify and propose the route
```task
id: MASON-WP-0009-T04
status: todo
priority: medium
```
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).