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.
This commit is contained in:
@@ -173,7 +173,23 @@ built too
|
||||
**genuinely verified**, like the OIDC login flow: Tantivy is an embedded
|
||||
library, not a networked service, so the isolation probe (three tenants,
|
||||
same search term, scoped search returns only that tenant's document)
|
||||
actually ran in this environment, no Docker needed. The deployment-
|
||||
actually ran in this environment, no Docker needed. That same
|
||||
Docker-free advantage is what caught a real bug while closing the last
|
||||
of Phase 4 task 8's four adversarial probes (a mid-provisioning tenant
|
||||
must be refused, not served): `search/src/registry.rs`'s `IndexRegistry`
|
||||
opened-or-created an index for any syntactically-valid `tenant_id`,
|
||||
meaning a query against a tenant that exists in `rbacstore` but isn't
|
||||
active yet would have silently returned zero results from a
|
||||
freshly-created empty index instead of being refused --
|
||||
`chrunner`'s ClickHouse routing had the equivalent guarantee for free
|
||||
(a mid-provisioning tenant simply isn't in its startup-built connection
|
||||
map) but Tantivy, a separate process with no Postgres access, had no
|
||||
way to know. Fixed with a new `enterprise/internal/searchclient.
|
||||
TenantChecker` (backed by `rbacstore.TenantIsActive`); both halves of
|
||||
the fix verified Docker-free (`chrunner_test.go`'s and
|
||||
`searchclient_test.go`'s `TestSearchRefusesMidProvisioningTenant`-shaped
|
||||
tests) — see `api/queryapi/tenant_isolation_gap_test.go` for the full
|
||||
accounting of all four probes, now all closed. The deployment-
|
||||
topology gap that briefly was the largest one is now closed for Helm:
|
||||
`deploy/helm/sentry/templates/api.yaml`/`enterprise-api.yaml` are
|
||||
mutually exclusive on the same `enterprise.enabled` flag that turns on
|
||||
|
||||
Reference in New Issue
Block a user