From 44cc067aa2c7dadffc75b631baa221a5f5caa531 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 4 Oct 2026 11:15:44 +0200 Subject: [PATCH] Name secrets-engine OpenBao registration and custody owner gates Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a1046b-5629-7f52-badd-f718eadb6042 --- docs/secrets-engine-openbao-owner-packet.md | 78 ++++++++++++++++ ...ets-engine-openbao-registration-custody.md | 93 +++++++++++++++++++ 2 files changed, 171 insertions(+) create mode 100644 docs/secrets-engine-openbao-owner-packet.md create mode 100644 workplans/KEY-WP-0037-secrets-engine-openbao-registration-custody.md diff --git a/docs/secrets-engine-openbao-owner-packet.md b/docs/secrets-engine-openbao-owner-packet.md new file mode 100644 index 0000000..dde3c42 --- /dev/null +++ b/docs/secrets-engine-openbao-owner-packet.md @@ -0,0 +1,78 @@ +# 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/services/keycape/secrets-engine-openbao, field CLIENT_SECRET. +- 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: an explicitly chosen mode-0600 file outside every Git + worktree, accepted by secrets-engine's service-auth provider. Its actual host, + owner, path, delivery mechanism and lifecycle must be named by secrets-engine + and platform before approval; no directory or secret value is guessed here. + +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. + +## 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. diff --git a/workplans/KEY-WP-0037-secrets-engine-openbao-registration-custody.md b/workplans/KEY-WP-0037-secrets-engine-openbao-registration-custody.md new file mode 100644 index 0000000..505ed49 --- /dev/null +++ b/workplans/KEY-WP-0037-secrets-engine-openbao-registration-custody.md @@ -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.