Open security core for dev sec ops on kubernetes
tegwick
2744ce7d36
tenant-engine assessed itself against the ladders and came back with corrections. All five are adopted, because the ratification test says that if a repo cannot express itself the ladders are wrong - and it could not, in three places. I2 conflated authority with verification. Its text named tenant-engine as the source of existence, which made the level describing canonical identity unclaimable by the service that provides it. An axis is assessed on a service's own inbound surface, never on its authority over the concept. tenant-engine is the source of tenant records and is at I1, because the acting identity arrives in the request body rather than in a verified token. A level now reports the weakest surface. tenant-engine has PDP-authorized mutations and three unauthorized read routes - including the one flex-auth calls for aal2-class decisions - and reported A2 rather than A3. Publishing the stronger surface would be accurate about that surface and misleading about the service. A per-surface vector was considered and rejected as premature. The E ladder assumed all data is tenant-keyed. A registry whose rows ARE the tenants has no predicate to scope a policy by, and enforcing one would break the service rather than secure it. Mixed-shape services now declare an E level plus a named registry exception; an unnamed exception is an overclaim. Without this they overclaim or sit at E2 forever, which is what tenant-engine was facing. Retention and erasure are two dimensions and one level cannot carry both. tenant-engine is R1 on backup and R0 on erasure - its lifecycle contract deliberately defines no hard-delete, so a tenant record cannot be deleted ever, by design, while carrying display_name and contact_email. Declared R1/R0 now. And the compounding - personal data, no erasure path, a backup window set by the longest-retaining co-resident - is the substrate owner's to surface, because each part looks locally reasonable alone. My own error, corrected: I listed tenant-engine as a live P1 occupant in both the ladder and the E/P matrix. They are on SQLite. P1 is TEN-WP-0009's target and the provisioning is my own unapplied intake. Asserting a placement that a workplan exists to create is exactly the kind of claim this document forbids. Worth recording: they found an unfiltered cross-tenant read in their own event accessor while assessing against the ladder, before publishing anything. 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.