Open security core for dev sec ops on kubernetes
tegwick
27a31f3f8f
All three repositories whose boundaries moved assented, each with a decision record (flex-auth FLEX-DEC-2026-001, kings-guard KG-DEC-2026-001, ops-warden ADR-0010), and each returned a finding. v0.2 carries the results and is accepted; v0.1 is marked superseded and retained because the twelve estate INTENT review notes cite it. - §5 restructured into three sanctioned shapes: read-only diagnostics, conduit (ops-warden's question, ruled), and declared engine gap (ops-warden's amendment, accepted). v0.1 offered only the first, which is narrower than the estate as it stands — a rule with no lane for a real sanctioned case gets satisfied by relabelling rather than by closing the gap. - §6.2 added: doctrine must reach the decision as an input claim or a versioned policy rule. This is §6.1 applied to gate-house on the same terms it applies to engines, drawn back by flex-auth. - §9 added: the catalog may not assign a capability the rules forbid discharging. Containment marked pending an engine surface; degraded-mode fallback ruled into access-engine rather than Staff. - §11: conformance now has three states, distinguishing a tracked gap from an undeclared violation. - §12 made normative, stating that an unsatisfiability finding is a success of the conformance loop. - §13 added: open gaps register, including the unowned approval storage and lifecycle capability — recorded, deliberately not assigned. 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.