Open security core for dev sec ops on kubernetes
tegwick
64394e99b9
The round returned findings from access-engine, approval-engine, ops-warden and net-kingdom. v0.8 stayed proposed throughout, so these are corrections to an uncut standard rather than amendments to an accepted one. §15 items 12-20 list them; §14 records what the round did and did not cover. The load-bearing one is §6.4 obligation 1. The obligation said a PEP must hold "a decision from access-engine", and obligation 2 supplied a digest test emphatic that it was mechanical rather than a matter of judgement. That test establishes which request a decision is for and nothing about who issued it, and it cannot: every input to it is either sent by the caller or published. Fail-closed protects against a decision point that is absent, not against one that lies. Obligation 5 was then written over a pair of artifacts whose authenticity only one half of could be validated, since §9.4 requires the approval object to have authenticated entries and nothing required it of the decision. The obligation now requires attribution, states that the digest comparison does not discharge it, and carries a declared §13 gap with access-engine as owner rather than a mechanism the standard does not get to choose. Obligation 3 gains three things: the drift test promoted SHOULD to MUST (the strongest obligation in the section had the weakest verification, in a paragraph arguing that drift is worse than no publication), a prohibition on totality satisfied by a catch-all, and the requirement that an absent scope be distinguishable in the record from an unknown one. The last closes the §16 question opened at the cut: absent fails closed too, for the stronger reason, and the distinction is in the record rather than in the stance. ops-warden asked for a dated transitional unknown: fail_open converting on coverage. Declined, with its reasons in §6.4: a sanctioned transitional fail_open is indistinguishable at runtime from the stance the rule forbids, and would make the rule optional at the only moment it costs anything. Its second preference is adopted instead — §13.1 records a dated classification-coverage figure beside each stance, so a strict consumer and an unclassified one stop reading alike. Its measured figures are in the register, and ops-mason's unpublished map is now marked as the plainer violation of the same obligation it always was. §6.4 announced four obligations and listed five. §17 called ownership of three artifacts unsettled while settling one of them in the same sentence. §14's tally could not be checked because item 2b's numbering left a reader unable to tell whether it was a change or a sub-clause. §19's hole was explained where nobody looks. All four found by approval-engine. 21 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012viPor8WJNCbV64ipwewrm Assistant: claude-code Assistant-Model: opus Assistant-Process: 1754332@bnt-lap001 Assistant-Session: 9c8ac536-ff5e-46a3-8ab1-a548bde25fc0 |
||
|---|---|---|
| .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.