Open security core for dev sec ops on kubernetes
tegwick
66dc491dc0
The standard is accepted at v0.7 on the owner's decision. §14 keeps two things apart, as ops-warden asked: boundary assent, given by four repositories at the version named in each record and undisturbed since; and revision review, where all four reviewed v0.6 and every change in v0.7 is the adopted remedy of a finding they raised. What is not claimed: nobody has reviewed v0.7 as text. Accepting a standard nobody has re-read is deliberate. The estate will learn more from using it than from another round of prose, and the v0.7 changes were requested rather than invented. Findings against the accepted text stay welcome — that is §12's normal business, not an exception. The companion moves from canon/standards to the repository root as SECURITY-COMPANION.md and becomes v0.2, so onboarding starts at the front door rather than three directories down. One copy, not two: a second copy of a fact is how the estate gets two sources for it. v0.2 closes the gap access-engine found in v0.1 — it said publish your stance map without saying where, and omitted the inventory obligation, so a repository could satisfy it faithfully and no register would learn of its stance. It also carries what v0.7 added: the corrected PEP obligations, the evidence threat decomposition with its stated residual, cadence as MUST for load-bearing sources with heartbeat for rare ones, the four agent rules and the glas-harness seam, and the Railiance axes with their unsettled mapping. It points readers at ops-warden for how to get things done. The companion says what the rules are; ops-warden stewards the paths through them. 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 | ||
| SECURITY-COMPANION.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-COMPANION.md — start here. The working form of the security layer model: what to declare, what binds you, what you may never claim about evidence, and the two things the estate cannot do yet
- Security layer model — the statute the companion serves (accepted 2026-08-29): 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.