jcoffey-dev
ba2276aa1a
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.
45 lines
2.4 KiB
Go
45 lines
2.4 KiB
Go
// This file is a checklist, not a fully passing test suite -- it exists
|
|
// so the four adversarial probes /docs/phase-4-isolation-design.md's
|
|
// "Verification plan for this design specifically" section names for
|
|
// Phase 4 task 8 have a permanent, grep-able home in the test tree.
|
|
//
|
|
// Three of the four are no longer blocked:
|
|
//
|
|
// - Item 1 (fully-qualified cross-tenant raw SQL):
|
|
// enterprise/internal/tenantprovision/tenantprovision_test.go's
|
|
// TestProvisionedUserCannotReadOtherTenantDatabase (raw ClickHouse-user
|
|
// layer) and enterprise/internal/chrunner/chrunner_test.go's
|
|
// TestRegistryTenantCannotReadOtherTenantEvenViaRawSQL (the actual
|
|
// query-execution code path, via enterprise/cmd/enterprise-api).
|
|
// - Item 2 (system.query_log/system.tables/SHOW DATABASES):
|
|
// enterprise/internal/tenantprovision/tenantprovision_test.go's
|
|
// TestProvisionedUserCannotReadSystemTables.
|
|
// - Item 3 (Tantivy cross-tenant search): search/src/registry.rs's
|
|
// tenant_index_is_isolated_from_default_and_other_tenants (Rust, the
|
|
// actual per-tenant index registry) and enterprise/internal/
|
|
// searchclient/searchclient_test.go (the Go client that resolves
|
|
// tenant_id from request identity, wire-level verified against a
|
|
// real in-process gRPC server).
|
|
//
|
|
// Item 4 remains blocked, for the reason its Skip below states. Note the
|
|
// scope boundary all three closed items share: they prove *read*
|
|
// isolation given tenant-scoped data exists -- they do not prove
|
|
// ingest/write-path tenancy, which doesn't exist yet (every record
|
|
// ingest produces lands in the single shared ClickHouse database and
|
|
// Tantivy index regardless of tenant) -- see
|
|
// /docs/security/threat-model.md.
|
|
package queryapi
|
|
|
|
import "testing"
|
|
|
|
func TestAdversarial_EvaluatorTickMidProvisioningIsRefusedNotServed(t *testing.T) {
|
|
t.Skip("BLOCKED on enterprise/internal/tenantprovision's ordered " +
|
|
"provisioning state machine (CREATE USER -> GRANT -> mark active): " +
|
|
"needs a tenant row that exists but hasn't reached the active gate " +
|
|
"yet, and a simulated /alerting evaluator tick against it, to " +
|
|
"confirm every tenant-resolution path actually checks tenant " +
|
|
"status server-side rather than inferring readiness from ambient " +
|
|
"connection success. See /docs/phase-4-isolation-design.md's " +
|
|
"verification plan, item 4, and its provisioning-gate requirement.")
|
|
}
|