jcoffey-dev
1d57e697b1
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.
deploy
Kubernetes deployment for Sentry, added in Phase 4 (/deploy was
deliberately stubbed through Phase 3 -- see /CLAUDE.md's Phase 3
non-goals). Two pieces:
operator/-- a small Go controller-runtime Operator managing one CRD (Tenant). Seeoperator/README.md.helm/sentry/-- a Helm chart covering everydocker-compose.ymlservice, plus the operator andTenantCRs whenenterprise.enabled=true. Seehelm/sentry/README.md.
What "multi-tenant-aware" means here, precisely
Per /docs/phase-4-isolation-design.md, tenant isolation itself lives at
the application layer inside enterprise/ (one api process holds a
map of per-tenant ClickHouse connection pools; one search process holds
a map of per-tenant Tantivy indices) -- not at the Kubernetes layer. This
directory is not "one Deployment per tenant" or a general
multi-cluster system; that's an explicit Phase 4 non-goal (see
/CLAUDE.md). What it does add, matching that same document's exit
criteria ("real per-tenant secret management, replacing today's single
shared CLICKHOUSE_PASSWORD"):
- A
TenantCRD + controller that generates and manages one dedicated ClickHouse credential Secret per tenant (operator/internal/controller). - A Helm chart that can install zero-or-more
TenantCRs (values.tenants) alongside the rest of the stack.
The Operator does not call ClickHouse (no CREATE DATABASE/CREATE USER/GRANT) and does not touch the Tantivy filesystem or
enterprise/internal/rbacstore -- that's enterprise/internal/ tenantprovision, still unbuilt (see the Phase 4 task 5 summary). A
Tenant reaching status.phase: Active here means "this tenant has a
K8s Secret," not "this tenant's ClickHouse database/grants exist" --
those are two different systems' state machines that aren't reconciled
together yet, named explicitly rather than implied.
Verification status -- read before trusting this against a real cluster
Not verified against a live Kubernetes cluster. This environment has
no kubectl/kind/minikube/kubebuilder/cluster reachable, so
nothing here has been kubectl apply'd or helm install'd for real.
Same disclosed-limitation shape as /agent/README.md's "Windows-specific
agent code remains unverified on real Windows" from Phase 1 -- a real gap
to close before shipping, not swept under the rug.
What was actually verified, offline, in this environment (network access was available to fetch these tools, but no cluster):
deploy/operator:go build/go vet/go test ./...all pass, including reconciler tests against controller-runtime's fake client (internal/controller/tenant_controller_test.go) -- real reconcile logic exercised, but not against a real apiserver (noenvtestbinaries available; see that test file's doc comment).deploy/operator/config/crd/sentry.io_tenants.yaml: parsed withsigs.k8s.io/yaml+ strict-unmarshaled into the realk8s.io/apiextensions-apiserverCustomResourceDefinitionGo type -- catches YAML syntax errors and structural mistakes, not a live-cluster admission check.deploy/helm/sentry:helm lintpasses;helm templaterenders cleanly under both default values and aenterprise.enabled: true+ two-tenant override; the rendered output was checked withkubeconform -strictagainst the real Kubernetes 1.31 OpenAPI schema for every built-in resource kind (22-29 resources depending on values, 0 invalid) -- this catches schema mistakes (wrong field names, wrong types) but not whether the resources actually reconcile correctly together on a live cluster (Job/StatefulSet startup ordering, PVC provisioning, actual pod scheduling).- Docker image builds (
operator/Dockerfileand every otherDockerfilethis chart references) were not verified in this session -- Docker's daemon wasn't reachable here either (see the Phase 4 task 5 conversation for why). Build and push every image this chart'svalues.yamlreferences before installing it.
Before relying on this in production: kind create cluster, helm install with --include-crds, and walk through
helm/sentry/README.md's two-tenant example end to end.