Open security core for dev sec ops on kubernetes
tegwick
da7747dc42
gate-house circulated v0.8 with two questions for this repository as owner of the NetKingdom emission-cadence security profile: whether §17's ownership paragraph reads in our own voice, and whether §11's new conformance item follows the profile or diverges from it. §17 is confirmed as written. It assigns the generic EmissionCadenceDeclaration contract to info-tech-canon and to net-kingdom the MUST/SHOULD split, the rare-class rate-monitoring prohibition, and the heartbeat-plus-reconciliation obligation — which is emission-cadence-security-profile_v0.1.md §3, conjunction included. No change. §11 diverged in both directions and is corrected. Requiring a detection surface of "heartbeat or reconciliation" of every load-bearing source withholds from a volume class the expected-rate form the profile permits, and accepts for a rare class either control alone where the profile — and the checker in tools/emission-cadence-profile — require both. A rare class covered by a heartbeat alone has no reconciliation to catch divergence, and one covered by reconciliation alone produces no claim that can go missing, which is the whole reason §9.6 rejects rate monitoring there. The item also contradicted its own following paragraph, which admits rate monitoring except where the class is rare. The check now defers the form to the governing profile rather than restating a split that is §17's to assign, carries the volume/rare distinction explicitly, and states that classification is the source's published inventory and never the checker's to infer from a name, payload, or observed rate — otherwise omission detection is circular. Change log item 6 and §14 record the review. The standard stays proposed; publication and the acceptance flip wait on the close of the circulation round. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ek3zTdfMa35bPVDjVUyhxx Assistant: claude-code Assistant-Model: opus Assistant-Process: 868701@bnt-lap001 Assistant-Session: b2e101b6-f501-40dc-9ee5-438cac36e21a |
||
|---|---|---|
| .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.