Open security core for dev sec ops on kubernetes
tegwick
745dffb8ac
From the independent assessment of 2026-08-29, which found the model sound as a layering constitution and incomplete as a self-healing one: cognition, authority, and execution are specified, but the two verbs that close a healing loop — observe in production, actuate through a deterministic surface — are pending, and one is unstaffed. Section numbers below §14 are unchanged; the estate cites them. - §3.3 types the Engine layer: PDP, PIP, Evidence, Lifecycle, with a role column in §4. Collapsing them hid different failure modes — a PIP outage is input degradation, a PDP outage is consumer residue, an evidence-plane outage must not block the operation it records. A new engine is a PIP unless amended. - §6.4 names the enforcement point. The standard was precise about the decision and silent about the gate, so enforcement lived in Staff runbooks. Four obligations: no side effect without a decision record, no local recaching of the verdict, a declared unreachable-engine stance, reconstructability. - §9.2 replaced. Containment was marked pending against kings-guard, the right mark on the wrong repository: reduce, step-up, and isolate are authority-changing operations, so they are rendered by an Engine and enforced by a PEP. Actuation is an unowned Engine concept held at zero. Staff proposes containment and never performs it. - §3.4 separates human and agent principals inside Staff — same permissions, different blast radius. No standing credential, conduit or engine API only, agent memory is not a state plane, every action reconstructable as the caller's. - §9.7 puts time into the model: explicit lifetimes, revocation visibility deadlines, consumption as a state change never inferred from a decision record, and the three race modes named. §9.8 states what holds under partition. - §17 requires the Taxonomy artifacts — claim, decision-record, gap-record, and emission-cadence schemas — without which §6.2 and §11 are reviewable but not compileable. Ownership proposed, not assigned. - §18 composes the sibling standards, which had been cited in frontmatter and nowhere in the rules. - §5 sunsets the uncatalogued-infrastructure carve-out. §5.3 declines a proposed fourth "operator of third-party Tooling" shape: it would convert a tracked gap into a permanent allowance, which is the relabelling failure this standard exists to prevent. - §10 gains the six artifacts a layer change must carry, written from the zone-engine case, including a permission freeze during the cut. - §2 lifts the observation rule so it cannot be lost in a summary. §13 separates its three normative rules from the table, now a snapshot due to move into maturity-engine. §16 decides the approval custody question: no. §19 records the fitness verdict. 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
- 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.