secrets-engine/docs/netkingdom-security-infrastructure.md
tegwick a852d3f1ff feat(mvp): working secrets-engine CLI for the whynot-design npm publish lane
Implements SECRETS-WP-0002 end to end as a uv-managed Python package:

- catalog: non-secret lane registry + strict validator (build/test/prod)
- stage roles + OpenBao ACL policies; guards refuse wildcards, sys/, identity/,
  admin names, and cross-stage paths before any backend call
- plan/apply: dry-run-first, idempotent policy + approle apply, decision-gated
- decisions: State Hub lookup with local-fixture fallback; non-secret evidence
  to JSONL + hub progress, scrubbed of any value
- provision/verify: mode-0600 file import + generated test values; positive/
  negative checks that never print the value
- exec delivery: `exec --catalog ... -- npm publish` injects the token via a
  temp .npmrc for the child only, cleaned up on exit/failure/interrupt
- ops-warden routing contract + hardening backlog docs
- 34 tests incl. live OpenBao integration; scripts/demo-e2e.sh runs the full
  chain against a throwaway bao dev server

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-28 12:28:45 +02:00

805 B

NetKingdom Security Infrastructure Boundary

The canonical document lives in the NetKingdom repository:

net-kingdom/docs/secrets-engine-security-infrastructure-boundary.md

Local checkout path:

/home/worsch/net-kingdom/docs/secrets-engine-security-infrastructure-boundary.md

This secrets-engine file is intentionally only a pointer. The canonical document belongs to NetKingdom because it defines cross-system security infrastructure responsibilities and boundaries across OpenBao, flex-auth, user-engine/key-cape, ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.

secrets-engine consumes that boundary and implements the secrets workflow, catalog, stage policies, OpenBao apply/delivery mechanics, and evidence model that the canonical document assigns to it.