Open security core for dev sec ops on kubernetes
tegwick
66eeabad38
Authored by gate-house under GH-WP-0003-T06; published here. v0.7 stays accepted and unedited until v0.8 is accepted in its place. Eleven changes across §6.4, §8, §9.5, §9.7.3, §11, §12, §13.1, §16 and §17, each carrying the decision record that already governs its implementers. Three correct a rule that was unsafe or unfalsifiable as written — consume ordering, the volatility boundary, and a permissive unknown. Three close gaps between rules already made. One corrects an ownership paragraph that a later decision made false, and §11/§12 gain the general form of that failure after six instances in one week. Ten of the eleven were requested by another repository, seven by a repository arguing against its own interest. §14 is therefore rewritten: this version is circulated for review rather than accepted on the owner's decision as v0.7 was, because it imposes costs on named repositories — ops-warden acquires a non-conformant stance cell, approval-engine an issue-time obligation — and a cost imposed without a review round is what §12 exists to catch late. Section numbering is unchanged; the estate cites it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WtJBr77gMFLrN93iEevqQJ Assistant: claude-code Assistant-Model: opus Assistant-Process: 425128@bnt-lap001 Assistant-Session: f5944d8b-dac4-4e1a-87eb-8b3d8f314a63 |
||
|---|---|---|
| .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
- Emission cadence security profile — NetKingdom obligations over the InfoTechCanon declaration contract; proposed pending owner-instance migration
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.