tegwick
44cc067aa2
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a1046b-5629-7f52-badd-f718eadb6042
78 lines
4.6 KiB
Markdown
78 lines
4.6 KiB
Markdown
# 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.
|