Open security core for dev sec ops on kubernetes
Four reviews. kings-guard found that v0.6 claimed a human/agent principal separation in §1 and §15 while §3.4 was byte-identical to v0.5: a silent edit failure, and their framing is the right one — a rule stated about a standard in its own change log is not a rule, which is §11's principle turned on the standard. The same failure had dropped two §16 entries. Both restored. §3.4 is now written: no standing credential, conduit or engine API only, agent memory is not a state plane, every action reconstructable as the caller's, and the seam with glas-harness for session semantics. The rest are collisions between rules each written for its own clean case: - §6.4(1) forbade what §6.4(3) blesses. A PEP may proceed under its declared §9.3 stance where the application of that stance is recorded in place of the decision — stricter than v0.6, since a fail-open result becomes metadata rather than silence. Raised by ops-warden, the reference shape it made a violation. - §6.4(2) forbade the session-bound allow §9.7.1 permits. Now scoped to replay outside the decision's own binding and lifetime, with access-engine's canonical request digest as the mechanical test. Negative caching ruled permitted where the refusal is recorded and the lifetime declared. - §13.1 now exists: v0.6 mandated a stance-map register and implemented none. Its first inventory has one row, which is the finding. - §9.6 gained a threat decomposition after audit-core corrected its own remedy: atomicity prevents accidental omission, cadence and reconciliation detect the adversarial case, nothing prevents it at a compromised source. Cadence is now MUST for load-bearing sources, with heartbeat or reconciliation required for low-volume classes where rate monitoring cannot work. - §9.7.2 splits by role: per input class at a PDP, one boundary deadline at a PEP. - §17 moves the decision-record schema to access-engine, which argued it against its own interest. - §13 stops attributing the actuation gap to kings-guard; §19 removed, since a verdict inside a standard grades the document it lives in. §20 records the Railiance interaction boundary on railiance-master's own definitions: the four axes, that a workload is a managed running deployable so approvals are never one, and that rein-* is not a fifth axis but a glas-harness concern. What is unsettled is listed as unsettled. 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 | ||
| .repo-manager | ||
| canon | ||
| capabilities/playbooks | ||
| docs | ||
| examples | ||
| history | ||
| identity-provisioner | ||
| intakes | ||
| 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
- Agent companion — the operative two-page form of that standard: what to declare, what binds you, what you may never claim
- 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.