Open security core for dev sec ops on kubernetes
tegwick
357109b2ab
audit-core, railiance-platform and flex-auth all reviewed. Every posture I guessed was too generous, on every repo that has now self-reported. Two of my statements about other repos were wrong as fact in canon. flex-auth does not call tenant-engine synchronously on the authorization path - the adapter is built and has no non-test caller, which is also why they cannot reach I3. And I justified A4 partly as ending the copying of action strings between repos; AuthZEN standardises the envelope and deliberately not the action vocabulary, so that argument is withdrawn and the interoperability one kept. Section 13.1 was found broken independently by audit-core and flex-auth: it required an evidence artifact for every claim while defining none below I2, A2, E1, P1, R2 - so section 5's own worked example of a conformant absorbed repo could not satisfy it on any axis. At or below the no-control rung a declaration now needs a stated reason, not an artifact. The weakest-surface rule from draft-6 was insufficient alone. A bare minimum destroys signal, since E3-write with E1-read declares identically to E1/E1. Declare per path, quote the minimum. Two services found this shape in themselves within a day, so it is the common case rather than a corner. n/a is now an admissible level. P0 presupposes a database and R0 presupposes retained data; a stateless service is neither, and without n/a a missing rung forces the fabrication section 6 prohibits - which is what draft-1 was rejected for. The A ladder had no seat for a decision point. flex-auth cannot occupy A3, since delegating to flex-auth is not something flex-auth can do. A PDP now declares two numbers: its own inbound level and the maximum it enables. They read A0 enables A3, which is more alarming than A3, which is the point. The ladders described consumers and not providers. railiance-platform showed apps-pg at I0 A0 E0 where the zeros are structural, and OpenBao at E0 where the mechanism in place is E4 machinery aimed at a consumer boundary - literally correct and inverting the real security position. A provider now declares what it makes reachable. Crypto-shredding needed a condition it did not have. audit-core showed that a hash over a low-entropy canonical record is a confirmation oracle, so destroying the key does not make content unrecoverable while the commitment survives - and that shreddability is not retrofittable onto a chain committing to cleartext. R4 by key destruction now requires that no retained commitment reveal the erased content. Section 9 named database credentials only; audit-core pointed out the argument applies with more force to the credential carrying the tenant claim. Extended. Section 17 led with the connection ceiling when memory binds first and fails worse. Corrected against rapp-postgres ADR-0004. Also: a low level may be permanent by design and the guard must not nag it, and the A4 evidence artifact now requires recording decision differences, since substitution proves interface portability rather than equivalence. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .claude | ||
| .forgejo/workflows | ||
| .githooks | ||
| canon | ||
| docs | ||
| examples | ||
| history | ||
| identity-provisioner | ||
| 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 provides a dynamic self optimizing full circle security-platform for kubernetes deployed IT-infrastructures.
Orientation
- SCOPE.md — what this repo owns, current state, and when it is relevant
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.