Open security core for dev sec ops on kubernetes
tegwick
31a49a43eb
secrets-engine found, and access-engine and approval-engine reported independently within hours, that GH-DEC-2026-008 as written was unimplementable. Where a claim travels inside the hashed request — the dual-control pattern it was written for — embedding the claim changes the digest of the request carrying it, so a digest recorded at issue can never equal the final one. It is a hash cycle. A fail-closed consumer obeying the rule would have denied destroy permanently. The comparison is now against the digest the PDP publishes for the request with the approval evidence excluded (flex-auth's binding.approval_binding_digest, verified present in its schema and tests). The exclusion rule is the PDP's to publish and a consumer MUST NOT guess it: a digest computed under an assumed rule fails open toward accepting a claim bound to a different request — the same failure direction as an invented vocabulary mapping, by another road. §6.4 obligation 5 gains the general property access-engine flagged as a near miss rather than a request: an evidence-bearing input may be excluded from a correspondence digest but never from the replay identity. Two requests differing only in which approval was presented decide differently, so collapsing them lets an allow obtained with a valid claim be replayed against a request carrying none — a fail-open hole reached by a refactor that looks like simplification. 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.