key-cape/docs/secrets-engine-openbao-owner-packet.md

# Secrets Engine OpenBao owner packet

Prepared 2026-10-04. Source preparation only; not approved for live execution.
Owning work: KEY-WP-0037-T02 (protected custody), T03 (live registration),
T04 (actual issuance evidence). Provider contract stays KEY-WP-0009 completed.

## Reviewed existing contract

KeyCape base: 672e1faf4b3401ff7bf68bb0b29f8dc50ca51ac6.
Accepted source: `config/service-clients.example.yaml` and
`docs/openbao-service-auth-contract.md`. Deployment authority:
`net-kingdom/sso-mfa/k8s/keycape/deployment.yaml` and deployment-owned config.
Existing preservation/rollout reference:
`net-kingdom/sso-mfa/k8s/keycape/approval-clients-rollout.py` and its synthetic
exercise/tests. That helper targets approval clients and must not be invoked
for this service registration without an owner-specific reviewed adaptation.

Exact registration: clientId/audience secrets-engine-openbao; subject
service:secrets-engine; principal_type service; tenant tenant:platform;
roles [secrets-engine]; scopes [openbao:login]; grants [client_credentials];
confidential; secretRef env:KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET;
tokenLifetime 15m. Issuer https://kc.coulomb.social, RS256 with JWKS /jwks,
POST /token and client_secret_basic. No resource-audience override, refresh
or ID token. AAL1 client-secret authentication never grants human approval.

## Candidate custody coordinates requiring owner acceptance

These are proposals, not existing allocated/provisioned resources:

- Authoritative platform KV candidate:
  platform/workloads/keycape/secrets-engine-openbao, field CLIENT_SECRET
  (corrected 2026-10-06 to the platform-mount rule; CCR-2026-0033).
- Issuer-side sso Secret candidate: keycape-secrets-engine-openbao-client,
  key client-secret, delivered from the exact KV field by an ESO reader scoped
  to that single path, 15-minute reader tokens and explicit safe target metadata.
- Only one new Deployment env reference: KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET
  from that Secret/key. Do not copy values into deployment YAML or config.
- Client-side consumer (superseded 2026-10-06 by founder direction and the
  ops-mason plan `plans/keycape-secrets-engine-openbao-client-custody.md`,
  MASON-WP-0009): there is no persistent workstation copy. The value lives only
  in OpenBao. secrets-engine reads it per command into memory through the attended
  OIDC role `keycape-secrets-engine-openbao-operator-workload-kv-read` on
  `auth/netkingdom`, then revokes that token.

Platform must allocate/review separate custody CCR and issuer-reader metadata.
The consumer file delivery cannot be treated as implied by issuer-side ESO.
A single random confidential value serves the issuer and the consumer in their
separate approved copies; approval/verifier/requester credentials stay separate.
No existing live version, receipt, protected copy or registration is asserted.

## KeyCape confirmation for the operator OIDC reader (2026-10-06)

The reader logs in through the `openbao-admin` public client (authorization
code, scopes include `groups`). Source behaviour at e22029e:

- Groups: human ID tokens always carry `groups` from LLDAP
  (`src/internal/server/oidc/token.go`, `claims["groups"]`), so
  `groups_claim: groups` with bound `net-kingdom-admins` is satisfiable. This
  matches CCR-2026-0019.
- MFA: `openbao-admin` has no `mfaRequired` pin. MFA is enforced because the
  deployed provider default is `privacyidea.requireForAll: true` (NetKingdom
  README). That is a deployment default rather than a client pin, so the role
  should bind the assurance claim as well: `bound_claims_type: string`,
  `"/assurance/level": "aal2"`. The token carries `assurance` as
  `{level, methods, mfa, at}`, and `aal2` appears only after a verified factor.
  Pinning `mfaRequired: true` on `openbao-admin` is the stronger NetKingdom
  option, but it changes every OpenBao admin login and needs its own go.

## Concrete preparation still required

1. Platform and secrets-engine accept/correct the proposed exact custody
   coordinates, and name consumer delivery plus revocation/rotation ownership.
2. Prepare the silent attended custody child with bounded generation/write,
   compare-before-write, no secret argv/output, native receipt, failure cleanup
   and version-preserving retry; fix consumer coordinates before founder approval.
3. NetKingdom prepares the exact-match single-client merge and one env binding,
   pins the actual image digest and source, verifies preservation/rollback with
   synthetic credentials and reviews cluster dry-run/diff/headroom. No blind
   whole-config reapplication or unrelated issuer changes.
4. Founder approves the exact separate live custody and registration packet.
   The previously approved informed-decision reader design grants neither.
5. Native live issuance validates signature and the complete claim set, denies
   wrong secret/excess scope, and verifies existing human login. After that,
   platform performs its separately approved isolated OpenBao provisioning and
   login-only policy proof, TTL/use-limit/expiry denial and explicit self-revoke.

Rollback removes only this new registration/binding after disabling issuance,
revokes the new readers, and destroys/retires the copies per the approved CCR.
Previously issued self-contained JWTs survive until 15-minute expiry; resulting
OpenBao tokens have independently bounded TTL/use limits. Avoid claiming instant
JWT recall. Cleanup failures remain unresolved evidence.

## Current evidence boundary

No live resources, registration, client secret, tokens or issuer were read or
changed by this review. Existing source tests can establish only the provider
contract. State Hub request b4fc62ea-f92c-4410-919a-9f3cce2d406b on thread
f84637fa-2355-4971-a2dc-7f1fd01710a8 requested the owner work; this packet closes
the missing owning-task identification, not the live acceptance gate.