Open security core for dev sec ops on kubernetes
tegwick
90cc64f728
v0.2 recorded the approval object as the one open architectural hole, and carried a latent instance of its own §9.1 rule: gate-house was catalogued as owning conformance review with no engine to act through. Two engines were seeded to close both. - §9.4: the approval object goes to approval-engine — not Staff (§3.4 forbids the runtime state), not access-engine (an evaluator owning what it evaluates is self-dealing), not audit-core (append-only is the opposite property). access-engine consumes approvals as input claims under §6.2; audit-core takes the tamper-evident evidence. Operative state and evidence record are separate artifacts with separate owners. - §9.5: graded progression goes to maturity-engine. gate-house judges and proposes; maturity-engine computes and remembers. Carries the guardrail that a level may never gate a decision directly — under §6.1 that would be a second decision point by the graded back door. - §4 catalog gained both engines; §13 register updated. Status proposed: the new engines are seeded by owner direction with no other side to assent yet, and the approval evidence half needs audit-core's assent. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9 |
||
|---|---|---|
| .claude | ||
| .forgejo/workflows | ||
| .githooks | ||
| canon | ||
| capabilities/playbooks | ||
| docs | ||
| examples | ||
| history | ||
| identity-provisioner | ||
| keys | ||
| local-identity | ||
| registry | ||
| sso-mfa | ||
| tests | ||
| tools | ||
| wiki | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| .sops.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| CONFIG.md | ||
| DECISIONS.md | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
NetKingdom
NetKingdom is the canonical security architecture, integration boundary, and bootstrap/reference implementation for NetKingdom environments. It defines identity, tenancy, credential, workload-zone, and security-composition contracts while leaving provider and Railiance execution in their owning repositories.
The dynamic, self-optimizing security platform is the long-term direction in INTENT.md, not a claim about current delivery.
Orientation
- SCOPE.md — what this repo owns, current state, and when it is relevant
- Security layer model — how the security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each layer may own
- Security scenario composition — deterministic, plan-only capability and trust composition
- Posture feedback — deterministic, proposal-only posture and evidence remediation findings
Security Infrastructure Documents
- secrets-engine security infrastructure boundary defines how secrets-engine participates in the NetKingdom security infrastructure and how it interacts with OpenBao, flex-auth, user-engine, ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.