Build per-tenant Tantivy write-routing, closing the last ingest write gap
search/src/consumer.rs now resolves each record's tenant_id Kafka header through the same IndexRegistry the read side (search/src/registry.rs + enterprise/internal/searchclient) already used, and writes into that tenant's own index instead of always the default one. The periodic Tantivy commit now commits every tenant index that's actually seen a write (IndexRegistry::commit_all), not just the default index. Unlike ClickHouse, this needed no "second binary": Tantivy has no grant system to gate a commercially-licensed credential behind, so IndexRegistry already lived directly in this AGPL-core search binary -- there was never an import-boundary reason to split the write side into an enterprise/ binary the way chwriter/enterprise-ingest was for ClickHouse. Read and write simply share one registry. Because Tantivy is an embedded library, this is genuinely verified in this environment, not just written: registry.rs's commit_all_commits_default_and_every_opened_tenant_index writes into the default index plus two tenant indices, confirms nothing is searchable pre-commit, then confirms all three are post-commit. consumer.rs's tenant_id_from_headers is factored out as a small pure helper (mirroring ingest/consumer.tenantIDFromHeaders) with its own unit tests, plus a guard test against the "tenant_id" header-key literal drifting from the Go side's -- the same guard-test pattern ingest/cmd/ingest already used for its own two Go copies of the constant, now mirrored a third time across the language boundary. One gap is disclosed, not fixed, by this change: unlike chwriter.Registry (an active-tenants-only snapshot built at enterprise-ingest startup, so an unrecognized tenant_id is refused outright) and unlike the read side (gated by searchclient.TenantChecker), this consumer's registry.resolve() call has no active-tenant check at all -- search has no Postgres access to check tenant status against. A still-valid-but-should-be-revoked ingest credential can cause an index directory to be created for a tenant that's no longer active. Narrow blast radius (an orphan, isolated, empty index, not cross-tenant leakage, and only reachable with a real signed credential), but real -- see registry.rs's doc comment on resolve(). Closing it fully would mean giving search some way to learn which tenants are active without an enterprise/ import, which isn't designed yet. This closes the last of Phase 4's ingest write-routing gaps (ClickHouse was closed last commit). The one remaining gap in the whole phase is now the tenant-picker frontend page, deliberately deferred earlier in this phase as out of scope for this environment.
This commit is contained in:
+28
-12
@@ -139,8 +139,8 @@ escape hatch is opaque to any compiler-injected filter.
|
||||
ran in the environment it was built in — Tantivy is an embedded
|
||||
library, so the cross-tenant isolation probe needed no live database
|
||||
or Docker to execute for real, and it passed.
|
||||
- **Ingest identity and ClickHouse write-routing are now built; Tantivy's
|
||||
isn't.** `ingest` (AGPL core) gained an optional `TenantResolver`
|
||||
- **Ingest identity, ClickHouse write-routing, and Tantivy write-routing
|
||||
are all now built.** `ingest` (AGPL core) gained an optional `TenantResolver`
|
||||
(`ingest/internal/grpcserver`): an agent presents a per-tenant bearer
|
||||
credential (`enterprise-auth -create-ingest-credential-tenant=<id>`
|
||||
mints one, only its hash stored), validated over the network via a new
|
||||
@@ -160,13 +160,28 @@ escape hatch is opaque to any compiler-injected filter.
|
||||
`SELECT` only, which would have made every real per-tenant write fail
|
||||
with a permission error — fixed by granting `SELECT, INSERT` (one
|
||||
credential, both directions; no cross-tenant boundary is crossed by
|
||||
also allowing INSERT within a tenant's own database). What isn't built
|
||||
yet: `search`'s independent Redpanda consumer (a different codebase —
|
||||
Rust — and a different process, not reachable through either `ingest`
|
||||
or `enterprise-ingest`) still writes every record into the one shared
|
||||
Tantivy index regardless of tenant. That's real, disclosed, separately
|
||||
scoped remaining work, not something this change claims to have
|
||||
closed.
|
||||
also allowing INSERT within a tenant's own database). `search`'s
|
||||
independent Redpanda consumer (a different codebase — Rust — and a
|
||||
different process, not reachable through either `ingest` or
|
||||
`enterprise-ingest`) is now write-routed too:
|
||||
`search/src/consumer.rs` resolves each record's `tenant_id` header
|
||||
through the *same* `IndexRegistry` the read side
|
||||
(`search/src/registry.rs` + `enterprise/internal/searchclient`)
|
||||
already used, and writes there instead of always into the default
|
||||
index. No "second binary" needed here, unlike ClickHouse — Tantivy has
|
||||
no grant system to gate a commercially-licensed credential behind, so
|
||||
`IndexRegistry` already lived directly in this AGPL-core binary, and
|
||||
read/write just share it. One gap is disclosed rather than closed by
|
||||
this change: unlike `chwriter.Registry` (an active-tenants-only
|
||||
snapshot built at startup) and unlike the read side (gated by
|
||||
`searchclient.TenantChecker`), this consumer's `resolve()` call has no
|
||||
active-tenant check — the process has no Postgres access to check
|
||||
against — so a still-valid-but-should-be-revoked ingest credential can
|
||||
cause an index directory to be created for a tenant that's no longer
|
||||
active. Narrow blast radius (an orphan, isolated, empty index, not
|
||||
cross-tenant leakage, and only reachable with a real signed
|
||||
credential), but real; see `search/src/registry.rs`'s doc comment on
|
||||
`resolve`.
|
||||
- `deploy/operator`'s `Tenant` CRD and `enterprise-api -provision-tenant`
|
||||
are now unified, deliberately lightweight: `-provision-tenant` stays
|
||||
the sole real actor (ClickHouse + `rbacstore`), and now also syncs its
|
||||
@@ -188,9 +203,10 @@ plain `api`), sharing a host-port/network-alias trick so `alerting`/
|
||||
`web` need no conditional config either way. With both storage engines'
|
||||
connection/index-layer mechanisms built, deployment topology enforced at
|
||||
both the Helm and docker-compose layers, and the two provisioning
|
||||
mechanisms unified, the largest remaining gap is ingest's per-tenant
|
||||
*write-routing* (identity is now attached at ingest time; nothing
|
||||
downstream of Redpanda consumes it yet to isolate the write, see above).
|
||||
mechanisms unified, and both storage engines' write paths now
|
||||
per-tenant-routed too (see above), the largest remaining gap in this
|
||||
phase is the tenant-picker *frontend* page — the backend protocol is
|
||||
built, but `web` has no session/cookie-handling code yet to call it.
|
||||
|
||||
## Licensing boundary
|
||||
|
||||
|
||||
+76
-23
@@ -38,6 +38,15 @@ of what was already run and passed. Two genuine exceptions:
|
||||
"email" -- crewjam's own fake IdP hit this path. Same remaining gap as
|
||||
OIDC: not yet tried against a real external IdP or a running
|
||||
`enterprise-auth` container.
|
||||
- Tantivy tenant isolation, both directions -- `search/src/registry.rs`'s
|
||||
cross-tenant read isolation (§9) and, since this pass,
|
||||
`search/src/consumer.rs`'s per-tenant write-routing (§14) -- verified
|
||||
live, no disclaimer needed, because Tantivy is an embedded library with
|
||||
no Docker/broker dependency: real indices, real documents, real
|
||||
commits, run in this environment. The one thing about it that's still
|
||||
unverified is not Tantivy itself but the upstream credential/header
|
||||
plumbing feeding it (ingest's `TenantResolver`, `enterprise-auth`'s
|
||||
`/internal/authorize-ingest`) against a real running stack.
|
||||
|
||||
Everything else — `internal/rbacstore`'s CRUD, the auth-enforcement
|
||||
walkthrough, the dashboards tenant-scoping fix, the Helm chart, the
|
||||
@@ -604,7 +613,7 @@ yet would refuse all ingest traffic outright rather than degrading
|
||||
gracefully. See §14 below for what the identity is actually used for on
|
||||
the write path.
|
||||
|
||||
## 14. Ingest write-routing (ClickHouse built, Tantivy not yet)
|
||||
## 14. Ingest write-routing (both storage engines)
|
||||
|
||||
`enterprise/cmd/enterprise-ingest` (mirrors `enterprise-api`'s "second
|
||||
binary" shape) consumes the `tenant_id` Kafka header §13 attaches and
|
||||
@@ -643,12 +652,50 @@ never actually executed -- "the test exists" is not the same claim as
|
||||
"write-routing is confirmed," same caveat §8 already states for the
|
||||
read-side `chrunner` tests.
|
||||
|
||||
**Not built**: Tantivy's side of this. `search/src/consumer.rs` is a
|
||||
completely independent Redpanda consumer, not called through `ingest` or
|
||||
`enterprise-ingest` at all, and does not read the `tenant_id` header --
|
||||
every record still lands in the one shared (default) Tantivy index
|
||||
regardless of tenant. See CLAUDE.md and `/docs/security/threat-model.md`'s
|
||||
"Read this first" for the full disclosure.
|
||||
**Tantivy's side is built too, and genuinely verified.**
|
||||
`search/src/consumer.rs` reads the same `tenant_id` Kafka header and
|
||||
resolves it through `search/src/registry.rs`'s `IndexRegistry` -- the
|
||||
same registry the read side (§9) already uses -- routing each record's
|
||||
write into its own tenant's Tantivy index instead of the single default
|
||||
one. No "second binary" was needed here the way ClickHouse needed
|
||||
`enterprise-ingest`: Tantivy has no grant system to gate a
|
||||
commercially-licensed credential behind, so `IndexRegistry` already
|
||||
lives directly in AGPL-core `search`, and read/write just share it.
|
||||
Because Tantivy is an embedded library (no Docker/broker needed to
|
||||
exercise real logic), this actually ran in this environment:
|
||||
|
||||
```sh
|
||||
cd search
|
||||
cargo test --quiet
|
||||
# registry.rs: commit_all_commits_default_and_every_opened_tenant_index
|
||||
# writes into the default index plus two tenant indices, confirms
|
||||
# nothing is searchable before commit_all(), then confirms all three ARE
|
||||
# searchable after -- the write-routing + periodic-commit path
|
||||
# end-to-end, for real, using the same real-Tantivy-index discipline as
|
||||
# every other registry.rs/index.rs test. consumer.rs:
|
||||
# tenant_id_from_headers_* cover the header-extraction helper
|
||||
# (missing/present/unrelated-header cases) and
|
||||
# test_tenant_id_header_key_matches_go guards the "tenant_id" literal
|
||||
# against drifting from ingest/consumer.TenantIDHeaderKey /
|
||||
# ingest/internal/grpcserver.TenantIDHeaderKey the same way
|
||||
# ingest/cmd/ingest's own guard test does on the Go side.
|
||||
```
|
||||
|
||||
**What's still not built, for either engine**: a live active-tenant
|
||||
recheck at write time. `chwriter.Registry`'s per-tenant writer map is a
|
||||
snapshot built once at `enterprise-ingest` startup from
|
||||
`rbacstore.ListProvisionedDataSources` (active tenants only) -- an
|
||||
unrecognized `tenant_id` is refused outright, but a tenant deprovisioned
|
||||
*after* startup keeps writing successfully until the next restart.
|
||||
`IndexRegistry.resolve()` has no allowlist at all on either the read or
|
||||
write side -- `search` has no Postgres access to check tenant status
|
||||
against -- so a still-valid-but-should-be-revoked ingest credential can
|
||||
cause an orphan Tantivy index directory to be created for a tenant
|
||||
that's no longer active. Narrow blast radius either way (isolated, not
|
||||
cross-tenant leakage, reachable only with a real signed credential), but
|
||||
real and disclosed, not silently accepted -- see
|
||||
`search/src/registry.rs`'s doc comment on `resolve` and
|
||||
`/docs/security/threat-model.md`'s "Read this first".
|
||||
|
||||
**Also not built**: Helm/`docker-compose.yml` do gate *whether*
|
||||
`enterprise-ingest` runs at all (`ingest.requireTenantCredential`, same
|
||||
@@ -688,22 +735,28 @@ Full accounting: `/docs/security/threat-model.md`. Headline items:
|
||||
that split (declarative request vs. imperative provisioning action)
|
||||
is intentional, not the "two disconnected sources of truth" gap this
|
||||
bullet used to describe.
|
||||
- **Ingest now has a real tenant identity (§13), and ClickHouse
|
||||
write-routing is built (§14) -- Tantivy write-routing is the one gap
|
||||
left.** An agent presents a bearer credential (`enterprise-auth
|
||||
-create-ingest-credential-tenant=<id>`), `ingest/internal/grpcserver.
|
||||
TenantResolver` validates it (fail-closed) and attaches the resolved
|
||||
tenant ID to every record as a `tenant_id` Kafka message header.
|
||||
`enterprise-ingest` reads that header back and routes each record's
|
||||
ClickHouse write into its own tenant's database (not yet confirmed
|
||||
against a real ClickHouse in this environment -- see §14). Nothing
|
||||
reads that header on the Tantivy side yet -- every record still lands
|
||||
in the one shared Tantivy index no matter what. A newly-provisioned
|
||||
tenant's ClickHouse database is real, isolated, and actually
|
||||
populated by write-routed traffic (once confirmed live); its Tantivy
|
||||
index remains real, isolated at query time, and permanently empty
|
||||
until Tantivy's write-routing split is built (a real, scoped
|
||||
follow-up, no longer an undesigned one).
|
||||
- **Ingest now has a real tenant identity (§13), and both storage
|
||||
engines' write-routing is built (§14).** An agent presents a bearer
|
||||
credential (`enterprise-auth -create-ingest-credential-tenant=<id>`),
|
||||
`ingest/internal/grpcserver.TenantResolver` validates it (fail-closed)
|
||||
and attaches the resolved tenant ID to every record as a `tenant_id`
|
||||
Kafka message header. `enterprise-ingest` reads that header back and
|
||||
routes each record's ClickHouse write into its own tenant's database
|
||||
(not yet confirmed against a real ClickHouse in this environment --
|
||||
see §14). `search/src/consumer.rs` reads the same header and routes
|
||||
each record into its own tenant's Tantivy index -- genuinely verified
|
||||
in this environment, unlike the ClickHouse side, since Tantivy needs
|
||||
no Docker to exercise real logic. Both engines share one remaining,
|
||||
disclosed gap: neither write path rechecks tenant-active status live
|
||||
(ClickHouse: a startup-time snapshot, stale until restart; Tantivy: no
|
||||
allowlist at all, since `search` has no Postgres access) -- narrow
|
||||
blast radius, not cross-tenant leakage, but real; see §14 and
|
||||
`/docs/security/threat-model.md`'s "Read this first". A
|
||||
newly-provisioned tenant's ClickHouse database and Tantivy index are
|
||||
both now real, isolated, and actually populated by write-routed
|
||||
traffic (the ClickHouse claim pending live confirmation, the Tantivy
|
||||
claim already verified) -- what used to be "permanently empty" for
|
||||
both is no longer true for either.
|
||||
- **Human SSO login now works for both OIDC (§3a) and SAML (§3b)** --
|
||||
each verified with a real fake IdP (genuine cryptographic signing and
|
||||
verification), not yet a real external IdP or a running
|
||||
|
||||
@@ -9,15 +9,21 @@ for the full design rationale behind the controls described here.
|
||||
|
||||
## Read this first: the single most important open finding
|
||||
|
||||
**Updated a third time.** This section originally read "log data
|
||||
**Updated a fourth time.** This section originally read "log data
|
||||
queried through `POST /query` is not tenant-isolated at all," then
|
||||
"ClickHouse is isolated but Tantivy isn't," then "ingest tags records
|
||||
with a tenant identity but nothing routes the write." Both ClickHouse
|
||||
*and* Tantivy connection/index-layer isolation are built on the *read*
|
||||
path, and ClickHouse write-routing is now built too. What's left is
|
||||
narrower but still real: **whether a given deployment actually runs the
|
||||
isolated binaries**, and **Tantivy's write path**, which still has no
|
||||
per-tenant routing at all.
|
||||
with a tenant identity but nothing routes the write," then "ClickHouse
|
||||
write-routing is built but Tantivy's isn't." Both storage engines are
|
||||
now isolated on both the read and write paths. What's left is narrower:
|
||||
**whether a given deployment actually runs the isolated binaries**
|
||||
(deployment-time, not code-level), and two disclosed write-side gaps,
|
||||
different in kind: ClickHouse's write registry is a startup-time
|
||||
snapshot of active tenants with no live recheck (a *deprovisioned*
|
||||
tenant can keep writing successfully until the next `enterprise-ingest`
|
||||
restart), while Tantivy's write path has no active-tenant allowlist at
|
||||
all — it opens an index for *any* syntactically-valid `tenant_id` a
|
||||
record carries, active, deprovisioned, or never real. See below for
|
||||
both, in full.
|
||||
|
||||
**ClickHouse (the SQL path) is built.** `enterprise/internal/
|
||||
tenantprovision` (real `CREATE DATABASE`/`CREATE USER`/`GRANT`) and
|
||||
@@ -70,43 +76,66 @@ provisioned, pointing at the same ClickHouse/Postgres. The Helm chart
|
||||
makes the *default*, chart-managed path correct; it isn't a runtime
|
||||
guard against misconfiguration.
|
||||
|
||||
**Ingest now has a real tenant identity, and ClickHouse write-routing is
|
||||
built — Tantivy write-routing is the one gap left.** `chrunner`/
|
||||
`searchclient` prove *read* isolation given tenant-scoped data exists; an
|
||||
optional `ingest/internal/grpcserver.TenantResolver` closes the "does a
|
||||
record know which tenant it belongs to" half by validating a per-tenant
|
||||
bearer credential an agent presents
|
||||
**Ingest now has a real tenant identity, and both storage engines'
|
||||
write-routing is built.** `chrunner`/`searchclient` prove *read*
|
||||
isolation given tenant-scoped data exists; an optional
|
||||
`ingest/internal/grpcserver.TenantResolver` closes the "does a record
|
||||
know which tenant it belongs to" half by validating a per-tenant bearer
|
||||
credential an agent presents
|
||||
(`enterprise-auth -create-ingest-credential-tenant=<id>` mints one; only
|
||||
its SHA-256 hash is ever stored) against a `POST
|
||||
/internal/authorize-ingest` endpoint, and attaching the resolved tenant
|
||||
ID to every record as a `tenant_id` Kafka message header before
|
||||
producing it — fail-closed: once a resolver is configured, a missing or
|
||||
invalid credential refuses the whole batch, never falls back to "no
|
||||
tenant." `enterprise/cmd/enterprise-ingest` (a second binary, mirroring
|
||||
`enterprise-api`) now consumes that header: it reuses `ingest/consumer`'s
|
||||
own flush loop with `enterprise/internal/chwriter.Registry` — a
|
||||
per-tenant `*clickhousewriter.Writer` registry, built the same way
|
||||
`chrunner`'s per-tenant connections are — swapped in as the writer, so a
|
||||
tagged batch's records are grouped by tenant and each group INSERTed
|
||||
through that tenant's own ClickHouse connection, fail-closed on an
|
||||
untagged or unprovisioned tenant. Building it surfaced a real gap in an
|
||||
already-shipped control: `tenantprovision.ProvisionClickHouse`'s grant
|
||||
was `SELECT`-only (correct for the read-side credential `chrunner` uses,
|
||||
but `chwriter` reuses the same credential for writes) — every real
|
||||
per-tenant write would have failed with a permission error until this
|
||||
was widened to `SELECT, INSERT`. **Not yet confirmed against a real
|
||||
ClickHouse**, same caveat as the read-side chrunner claim above — the
|
||||
Docker-free fail-closed tests pass, the live-database tests are written
|
||||
but skip-gated, see `/docs/phase-4-runbook.md`. What's still missing:
|
||||
`search`'s independent Redpanda consumer does not read the `tenant_id`
|
||||
header at all — every ingested record still lands in the one shared
|
||||
(default) Tantivy index regardless of tenant. A newly-provisioned
|
||||
tenant's ClickHouse database is now real, isolated, and actually
|
||||
populated by write-routed agent traffic (once confirmed against a real
|
||||
cluster); its Tantivy index remains real, isolated, and queryable
|
||||
through `enterprise-api` — and permanently empty, until Tantivy's own
|
||||
write-routing split is built, which is now scoped, disclosed remaining
|
||||
work, not an undesigned gap.
|
||||
tenant."
|
||||
|
||||
**ClickHouse**: `enterprise/cmd/enterprise-ingest` (a second binary,
|
||||
mirroring `enterprise-api`) consumes that header: it reuses
|
||||
`ingest/consumer`'s own flush loop with `enterprise/internal/
|
||||
chwriter.Registry` — a per-tenant `*clickhousewriter.Writer` registry,
|
||||
built the same way `chrunner`'s per-tenant connections are — swapped in
|
||||
as the writer, so a tagged batch's records are grouped by tenant and
|
||||
each group INSERTed through that tenant's own ClickHouse connection,
|
||||
fail-closed on an untagged or unprovisioned tenant. Building it surfaced
|
||||
a real gap in an already-shipped control: `tenantprovision.
|
||||
ProvisionClickHouse`'s grant was `SELECT`-only (correct for the
|
||||
read-side credential `chrunner` uses, but `chwriter` reuses the same
|
||||
credential for writes) — every real per-tenant write would have failed
|
||||
with a permission error until this was widened to `SELECT, INSERT`.
|
||||
**Not yet confirmed against a real ClickHouse**, same caveat as the
|
||||
read-side chrunner claim above — the Docker-free fail-closed tests pass,
|
||||
the live-database tests are written but skip-gated, see
|
||||
`/docs/phase-4-runbook.md`.
|
||||
|
||||
**Tantivy**: `search/src/consumer.rs` now resolves each record's
|
||||
`tenant_id` header through the *same* `IndexRegistry` the read side
|
||||
already used (`search/src/registry.rs`), and writes there instead of
|
||||
always into the default index — genuinely verified in this environment,
|
||||
same as the read-side Tantivy claim above, since Tantivy is an embedded
|
||||
library with no Docker dependency. No "second binary" was needed here,
|
||||
unlike ClickHouse: Tantivy has no grant system to gate a
|
||||
commercially-licensed credential behind, so `IndexRegistry` already
|
||||
lived directly in this AGPL-core `search` binary, and read/write simply
|
||||
share it.
|
||||
|
||||
**Both engines share one open question** — deployment topology, covered
|
||||
above — and Tantivy specifically has one gap ClickHouse's design doesn't:
|
||||
`chwriter.Registry`'s map is built once at startup from an
|
||||
active-tenants-only query, so an unrecognized `tenant_id` is refused
|
||||
outright; `IndexRegistry.resolve()` (used for both read and write) has
|
||||
no equivalent allowlist at all, because `search` has no Postgres access
|
||||
to check tenant status against — a syntactically-valid `tenant_id` on a
|
||||
still-valid-but-should-be-revoked ingest credential can cause an orphan
|
||||
index directory to be created for a tenant that's no longer active.
|
||||
Narrow blast radius (isolated, empty except for that traffic, not
|
||||
cross-tenant leakage, and reachable only with a real signed credential),
|
||||
but real, and not closed by this change; see
|
||||
`search/src/registry.rs`'s doc comment on `resolve`. A newly-provisioned
|
||||
tenant's ClickHouse database and Tantivy index are both now real,
|
||||
isolated, and actually populated by write-routed agent traffic (the
|
||||
ClickHouse claim pending live confirmation, the Tantivy claim already
|
||||
verified).
|
||||
|
||||
## System overview
|
||||
|
||||
@@ -146,13 +175,14 @@ sentryctl ──▶ api, alerting (Bearer token when SENTRYCTL_TOKEN is set)
|
||||
Ingest path (agent → Redpanda → ingest → ClickHouse, and Redpanda →
|
||||
search → Tantivy): `ingest` resolves and tags each record with a real
|
||||
tenant ID (see "Read this first" above). `enterprise/cmd/enterprise-ingest`
|
||||
now consumes that tag and routes ClickHouse writes to each tenant's own
|
||||
database. Tantivy's independent Redpanda consumer (`search/src/
|
||||
consumer.rs`) still does not consume the tag at all — every record still
|
||||
lands in the one shared Tantivy index regardless of tenant. That
|
||||
narrower gap is still out of scope for what's built so far and is not
|
||||
separately designed in `/docs/phase-4-isolation-design.md`; named here as
|
||||
a gap that design doc doesn't yet cover, not just an implementation gap.
|
||||
consumes that tag and routes ClickHouse writes to each tenant's own
|
||||
database. `search/src/consumer.rs` (Tantivy's independent Redpanda
|
||||
consumer) consumes the same tag and routes each record into its own
|
||||
tenant's index. Both write paths' one remaining gap — no live
|
||||
active-tenant recheck (ClickHouse: a startup-time snapshot; Tantivy: no
|
||||
allowlist at all) — is named in "Read this first" above, not separately
|
||||
designed in `/docs/phase-4-isolation-design.md`; named here as a gap that
|
||||
design doc doesn't yet cover, not just an implementation gap.
|
||||
|
||||
## Module boundary (trust boundary #1)
|
||||
|
||||
@@ -454,8 +484,8 @@ terms:
|
||||
| Tantivy per-tenant index routing (`search/src/registry.rs`) | **Enforced, verified live** — real Tantivy indices, real cross-tenant probe, all passing |
|
||||
| Tantivy tenant_id resolution (`enterprise/internal/searchclient`) | **Enforced, verified live** — real gRPC wire-level test |
|
||||
| Ingest tenant *identity* (credential validation, tagging) | **Built and tested** — fail-closed `TenantResolver`, `tenant_id` Kafka header attached per record |
|
||||
| Ingest tenant *write-routing*, ClickHouse | **Built, not yet confirmed against a real ClickHouse** — `enterprise-ingest`/`chwriter.Registry` route each tagged batch to its tenant's own database, fail-closed on an untagged/unprovisioned tenant; Docker-free tests pass, live-database tests are skip-gated |
|
||||
| Ingest tenant *write-routing*, Tantivy | **Not implemented, now scoped** — every record still lands in the single shared Tantivy index regardless of tenant; `search/src/consumer.rs` consuming the tenant_id header to route the write is real, disclosed remaining work |
|
||||
| Ingest tenant *write-routing*, ClickHouse | **Built, not yet confirmed against a real ClickHouse** — `enterprise-ingest`/`chwriter.Registry` route each tagged batch to its tenant's own database, fail-closed on an untagged/unprovisioned tenant; Docker-free tests pass, live-database tests are skip-gated. Startup-time active-tenant snapshot, no live recheck — a deprovisioned tenant can keep writing until the next restart |
|
||||
| Ingest tenant *write-routing*, Tantivy | **Built and genuinely verified** — `search/src/consumer.rs` routes each record into its own tenant's index via `IndexRegistry`, same registry the (already-verified) read side uses; no Docker needed, real tests pass. No active-tenant allowlist at all on write (`search` has no Postgres access) — a syntactically-valid `tenant_id` on a still-valid credential can create an orphan index for a no-longer-active tenant; narrow, disclosed, not cross-tenant leakage |
|
||||
| Deployment actually routing traffic to `enterprise-api` (Helm) | **Enforced** — `api`/`enterprise-api` are mutually exclusive, same flag as RBAC/audit/SSO |
|
||||
| Deployment actually routing traffic to `enterprise-api` (docker-compose) | **Enforced** — `api`/`enterprise-api` are mutually exclusive via `COMPOSE_PROFILES`, same flag choice as Helm's `enterprise.enabled`; verified via `docker compose config`, not an actual `docker compose up` in this environment |
|
||||
| Human SSO login — OIDC | **Built, verified with a real fake IdP** (not yet tried against a real external IdP) |
|
||||
|
||||
Reference in New Issue
Block a user