tegwick
5b48033bce
Token scope is now bound to package maturity, gated on netkingdom's own maturity: - maturity-build -> gitea-wide, maturity-test -> org-wide, maturity-prod -> repo-scoped (scope narrows as stakes rise; broad tokens only for low-stakes build artifacts) - the graduated table is DORMANT until netkingdom reaches production grade; until then every lane clamps to repo-scope, injected as NPM_AUTH_TOKEN (fail-safe) - token env-var name signals blast radius: NPM_AUTH_TOKEN (repo default), NPM_AUTH_COULOMB_TOKEN (org), NPM_AUTH_GITEA_TOKEN (gitea), NPM_AUTH_WHYNOT_TOKEN (npm scope, defined but unused), NPM_AUTH_WHYNOTDESIGN (explicit repo) netkingdom is at maturity-build today, so whynot-design resolves to repo-scope / NPM_AUTH_TOKEN. Flip netkingdom_maturity to maturity-prod to activate graduation. - policies/netkingdom-publication-scope.yaml: the policy data + gate - publication_policy.py: load + resolve (clamp/active, env naming, override) - exec delivery injects under the resolved env-var name (was fixed SE_NPM_TOKEN) - catalog lane carries delivery_config.npm.maturity - new CLI: `secrets-engine policy publication <lane>` - docs/publication-scope-policy.md; tests for clamp, graduation, naming, override Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2.9 KiB
2.9 KiB
secrets-engine
Headless, multi-application, multi-tenant secrets workflow and automation layer for approved secret custody, delivery, and lifecycle work across build, test, and production stages.
OpenBao remains the custody and enforcement backend. secrets-engine owns the
operator and agent interaction model: catalog, decision checks, plan/apply,
safe provisioning, verification, delivery, evidence, rotation, and deactivation.
Start Here
- INTENT.md - why this repository exists.
- ProductRequirementsDocument.md - product requirements and MVP scope.
- NetKingdom security infrastructure boundary pointer
- points to the canonical document in
net-kingdom/docs/, covering responsibilities and interactions with OpenBao, flex-auth, user-engine, ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.
- points to the canonical document in
- Bootstrap MVP workplan - first implementation plan after State Hub bootstrap.
Core Direction
The MVP proves the whynot-design-npm-publish lane end to end:
- describe the lane in a non-secret catalog (
catalog/); - verify an approved decision (State Hub or local fixture);
- apply OpenBao policy/auth metadata through a stage-aware role;
- provision and verify the value without printing it;
- run a workload command through safe exec-time delivery.
Target command shape:
secrets-engine exec --catalog whynot-design-npm-publish -- npm publish
Quickstart
uv venv && uv pip install -e ".[dev]"
source .venv/bin/activate
secrets-engine catalog list
# Run the whole pilot chain live against a throwaway OpenBao dev server:
SECRETS_ENGINE_HUB_URL="" bash scripts/demo-e2e.sh
- CLI reference: docs/cli.md
- Publication-scope policy (maturity → token scope): docs/publication-scope-policy.md
- Stage roles & bootstrap tokens: docs/openbao-stage-roles.md
- ops-warden routing contract: docs/ops-warden-routing-contract.md
- Hardening backlog (exit bootstrap mode): docs/hardening-backlog.md
The implementation is a Python package (src/secrets_engine/). OpenBao is
reached only through the bao CLI adapter (openbao.py); the rest of the code
speaks in lanes and guarded plans.
Security Rules
- Do not put raw secret values in Git, State Hub, chat, prompts, issue comments, workplans, or normal logs.
- OpenBao is the backend custody and audit authority.
- Build, test, and production have separate policy boundaries.
- Production actions require approved decisions except explicit break-glass flows.
- Temporary bootstrap OpenBao credentials must live outside repos, use mode 0600, be revocable, and be removed after narrower auth is working.