Open security core for dev sec ops on kubernetes
tegwick
8a17551103
v0.6 is dense, self-referential, and written for readers who already live in the estate. That is acceptable in canon and poor as a contract for the nine repositories yet to declare and for the Staff agents expected to conform. The companion is the operative form: the rules, no change log, no review archaeology. Machine-readable layer key, the three sanctioned Tooling shapes as a table, the PEP obligations, the evidence bound with the two unsound claims written out, the four agent rules, and the four conformance states. The statute governs on disagreement, and a disagreement is reportable as a finding. Its §9 records that operations is HelixForge's responsibility — reef, rail, rapp, rein — consuming the NetKingdom security and approval framework, and that the interface is NOT yet specified. What holds today is only what holds for any consumer. No mapping of those concepts onto the layer model should be assumed until it is written; the statute's §16 carries the same open question. Its §10 states the two things the estate cannot do yet — nothing is observed in production, nothing can be contained automatically — so no reader plans around a capability that does not exist. 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.