3 Commits

Include renames

Author	SHA1	Message	Date
jcoffey-dev	2e698f5623	Close the last tenant-isolation adversarial probe (mid-provisioning tenants) ... Phase 4 task 8's verification plan named four adversarial probes; three were closed earlier this phase, the fourth (an evaluator tick, or any other caller, hitting a tenant that exists but hasn't reached the active+credentialed gate yet -- must be refused, not served) was still an explicitly-skipped stub in api/queryapi/tenant_isolation_gap_test.go. Investigating it found the two storage engines needed genuinely different treatment: - ClickHouse (enterprise/internal/chrunner) already had this property structurally, for free: Registry is built once at startup from rbacstore.ListProvisionedDataSources, which already filters to active+credentialed tenants only, so a mid-provisioning tenant is simply absent from the connection map. New test TestRegistryRefusesMidProvisioningTenant proves this without Docker -- an empty DataSource list never dials ClickHouse, so this genuinely runs in this environment, unlike every other test in that file. - Tantivy (search/src/registry.rs's IndexRegistry) was a real, different gap, not just an unverified assumption: it opens-or-creates an index for any syntactically-valid tenant_id on first request, because it's a separate process with no Postgres access and structurally can't know which tenants are actually provisioned. A query against a mid-provisioning tenant would have silently succeeded with zero results from a freshly-created empty index -- "ambient success" indistinguishable from "no matching logs," exactly the failure mode this item was worried about. Fixed the Tantivy gap with a new enterprise/internal/searchclient. TenantChecker interface (backed by a new rbacstore.TenantIsActive, implemented structurally, no new import edge needed), consulted before every gRPC call: Client.Search now refuses a non-active tenant before it ever reaches `search`. Dial's signature gained a required TenantChecker parameter; enterprise-api's main.go passes its existing rbacstore.Store (already satisfies the interface). Verified Docker-free via searchclient's existing real-in-process-gRPC-server test harness (TestSearchRefusesMidProvisioningTenant, plus TestSearchPropagatesTenantCheckerError for the fail-closed-on-error case) -- both genuinely run in this environment, same bar as the rest of the Tantivy isolation work. rbacstore.TenantIsActive itself has two new skip-gated live-Postgres tests (TestTenantIsActive, TestTenantIsActiveNonexistentTenant) -- disclosed as not run against a live database here, same gap as the rest of this phase's Postgres-backed pieces. api/queryapi/tenant_isolation_gap_test.go rewritten from a checklist with one skipped stub to a full accounting of all four now-closed probes. Docs updated in lockstep: CLAUDE.md, threat-model.md, phase-4-isolation-design.md (implementation note added after its original sign-off), phase-4-runbook.md (§9), enterprise/README.md.	2026-08-14 08:07:52 -07:00
jcoffey-dev	ba2276aa1a	Phase 4: real Tantivy per-tenant isolation (search/src/registry.rs, enterprise/internal/searchclient) ... Closes the last named "isolation mechanism" gap: search.proto gains a tenant_id field on SearchRequest; search/src/registry.rs's IndexRegistry resolves it to an on-demand-opened, per-tenant Tantivy index (empty tenant_id keeps today's single default index, so this is purely additive); enterprise/internal/searchclient sets that field from the authenticated request identity in ctx, mirroring chrunner's exact fail-closed "never a parameter" shape. Wired into enterprise-api in place of the shared api/searchclient. Unlike the ClickHouse pieces from the previous two commits, this one is genuinely verified end to end in this environment: Tantivy is an embedded library, not a networked service, so both the Rust index registry (cargo test, cargo clippy --all-targets -- -D warnings, both clean) and the Go client (a real in-process gRPC server) could actually run. registry.rs's tenant_index_is_isolated_from_default_and_other_tenants seeds three real indices with the same term and confirms a tenant-scoped search returns only that tenant's document -- item 3 of the isolation design doc's verification plan, closed for real, not just written. With both ClickHouse and Tantivy isolation now built, the single largest remaining gap is no longer a missing mechanism: it's that nothing forces or flags whether a deployment actually runs enterprise-api instead of plain api, and that ingest itself has no tenant concept for either storage engine (every record still lands in the one shared database/ index no matter what -- undesigned, not just unbuilt). Updated the threat model, architecture doc, CLAUDE.md, and both READMEs accordingly.	2026-08-13 23:16:22 -07:00
jcoffey-dev	1d57e697b1	Phase 4: real per-tenant ClickHouse isolation via a new enterprise-api binary ... Closes the threat model's headline finding for the SQL query path: enterprise/internal/tenantprovision does real CREATE DATABASE/USER/GRANT against ClickHouse, and enterprise/internal/chrunner is a per-tenant connection registry implementing api's SQLRunner interface, resolving the tenant from the authenticated request identity -- never a caller-suppliable parameter. Both are wired into a new binary, enterprise/cmd/enterprise-api, alongside the unchanged single-tenant api/cmd/api, since AGPL core can never import enterprise/ and Go's own internal/ package visibility rules meant enterprise/ couldn't implement core's SQLRunner interface without importing the package that defines it. That required moving api/internal/{authz,queryapi,dashboards, querylang/executor,searchclient,httpserver} out of internal/ -- the minimal set enterprise-api needs to import; querylang's compiler internals (planner/lexer/parser/ast/ir) and api's own config stay internal, since nothing outside api needs them directly. Also finally wires enterprise/internal/audit into queryapi.AuditLogger (nil since Phase 4 task 4) via a new adapter, and adds live-ClickHouse integration tests for two of the four adversarial probes named in docs/phase-4-isolation-design.md's verification plan. Corrected several overclaims in the docs while writing this up: an earlier claim that rbacstore's CRUD was "verified against a live Postgres" was never actually true in this environment (only internal/audit was, earlier in this phase, before Docker access was lost) -- threat-model.md, phase-4-runbook.md, CLAUDE.md, and enterprise/README.md all now distinguish "a real integration test exists" from "this was confirmed against a live database." Still not built: Tantivy/free-text tenant isolation (enterprise/internal/searchclient), and any deployment-topology mechanism that actually routes traffic to enterprise-api instead of plain api -- both binaries exist side by side today with nothing enforcing or flagging which one a deployment runs.	2026-08-13 22:48:38 -07:00