Name secrets-engine OpenBao registration and custody owner gates

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1046b-5629-7f52-badd-f718eadb6042
This commit is contained in:
tegwick 2026-10-04 11:15:44 +02:00
parent 672e1faf4b
commit 44cc067aa2
2 changed files with 171 additions and 0 deletions

View file

@ -0,0 +1,93 @@
---
id: KEY-WP-0037
type: workplan
title: "Secrets Engine OpenBao live registration and protected custody"
domain: infotech
repo: key-cape
status: active
owner: codex
topic_slug: netkingdom
created: "2026-10-04"
updated: "2026-10-04"
---
KeyCape's accepted provider contract (KEY-WP-0009) does not establish actual
registration or custody. This plan names those missing owner gates for
RPF-WP-0035-T02. The founder authorized workers to attend the review requests,
not live registration, credential generation, rotation, fetching or deployment.
## Establish the exact registration and deployment authority
```task
id: KEY-WP-0037-T01
status: done
priority: high
```
Reviewed KeyCape base 672e1faf4b3401ff7bf68bb0b29f8dc50ca51ac6:
`config/service-clients.example.yaml`, `docs/openbao-service-auth-contract.md`,
`src/internal/config/config.go`, `src/cmd/keycape/clients_test.go`.
The exact service registration remains accepted: secrets-engine-openbao,
service:secrets-engine, tenant:platform, role secrets-engine, only openbao:login,
client_credentials, confidential, tokenLifetime 15m and issuer
https://kc.coulomb.social. Audience defaults to clientId, with no resource
audience override. See the owner packet for concrete deployment/custody proposals.
NetKingdom owns the live sso/keycape deployment and config, not this example.
Existing approved approval-client rollout demonstrates the owner procedure;
it does not approve or provision this different service client.
## Agree and prepare the separately approved protected custody operation
```task
id: KEY-WP-0037-T02
status: wait
priority: high
needs_human: true
intervention_note: "Approve the exact separate secrets-engine-openbao custody boundary only after platform and consumer owners complete the proposed coordinates and reviewed execution packet. Informed-decision reader approval does not cover this client."
```
Platform owns the authoritative OpenBao client-secret custody and least-privilege
issuer-side delivery; secrets-engine owns its explicitly selected mode-0600
client-side file outside every worktree. The proposal in
`docs/secrets-engine-openbao-owner-packet.md` provides candidate coordinates,
not a live custody claim or allocated CCR. Complete the platform CCR(s), delivery
policy/roles, two target bindings, exact attended child and rollback before
seeking the founder's separate concrete approval. Values stay out of Hub/Git/chat,
argv and logs. Existing verifier/requester values must not be reused.
## Prepare and approve the deployment-owned registration operation
```task
id: KEY-WP-0037-T03
status: wait
priority: high
depends_on:
- KEY-WP-0037-T02
```
Coordinate source registration merge and the single new env secretKeyRef with
NetKingdom's `sso-mfa/k8s/keycape/deployment.yaml` and owner rollout implementation.
An exact reviewed source revision, image digest, config preservation test,
synthetic issuance/denial verification and founder live go are required.
Use an idempotent exact-match merge: absence permits adding only this client;
matching client permits noop; duplicates or drift fail closed. Preserve signing
key, unrelated clients, existing policy and confidential config bytes.
No deployment changes are authorized by this source plan.
## Verify actual issuance and publish non-secret owner receipt
```task
id: KEY-WP-0037-T04
status: wait
priority: high
depends_on:
- KEY-WP-0037-T03
```
After authorized registration and custody, verify issuer/JWKS signature, subject,
audience, principal_type, tenant, roles, scope and 900-second lifetime; refuse
wrong credential/excess scope and preserve existing human login. Record only
booleans and identities, immutable image/source coordinates and custody binding
metadata. Hand off to RPF-WP-0035-T02 for isolated OpenBao metadata provisioning,
claim/expiry/use-limit denial and self-revocation proof. Never report an example
registration, discovery metadata or source test as live acceptance.