Files
cairnobs/deploy/helm/sentry/templates/ingest.yaml
T
jcoffey-dev 1de77b969f Build per-tenant ClickHouse write-routing for ingest (Tantivy still deferred)
ingest tags every record with a tenant_id Kafka header (built previously),
but nothing consumed it to actually route the write. This closes that for
ClickHouse: enterprise/cmd/enterprise-ingest (a second binary, mirroring
enterprise-api) reuses ingest/consumer's own flush loop unchanged, with
enterprise/internal/chwriter.Registry -- a per-tenant clickhousewriter.Writer
registry -- swapped in as the writer. A batch pulled from the single shared
Redpanda topic can mix records from many tenants, so WriteBatch groups by
TenantID and dispatches each group to its own tenant's connection, fail-
closed on an empty or unrecognized tenant_id.

ingest/consumer and ingest/clickhousewriter move out of internal/ (same
reason api/internal/* moved earlier this phase: enterprise/ can't import
anything under another module's internal/). Their New() constructors now
take small local Config structs instead of ingest/internal/config types,
so enterprise/ doesn't need that import either.

Building this surfaced a real bug: tenantprovision.ProvisionClickHouse
only granted SELECT on a tenant's ClickHouse user, correct for chrunner's
read-only use but not enough for chwriter reusing the same credential to
write -- every real per-tenant write would have failed closed with a
permission error. Fixed by widening the grant to SELECT, INSERT; no
cross-tenant boundary is crossed by also allowing INSERT within a
tenant's own database.

Helm gates enterprise-ingest's Deployment on the same
ingest.requireTenantCredential flag that already gates tag validation --
write-routing is meaningless without tagging already being required, so
they're one decision, not two. docker-compose.yml's version is a
disclosed, weaker approximation: it can't achieve Helm's genuine
-mode=server/-mode=consumer split, so with the enterprise profile active
both ingest and enterprise-ingest independently consume every message
via different consumer groups -- harmless duplication for local
verification only.

Not built: Tantivy's independent Redpanda consumer (search/src/consumer.rs)
still doesn't read the tenant_id header at all -- every record still lands
in the one shared index regardless of tenant. Not run: the live-ClickHouse-
gated tests (chwriter's cross-tenant routing test, tenantprovision's INSERT
regression test) -- no Docker/database access in this environment; they're
correct Go that has never executed, disclosed as such in docs/security/
threat-model.md and docs/phase-4-runbook.md §14.
2026-08-14 19:26:09 -07:00

96 lines
4.0 KiB
YAML

apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-ingest
labels:
{{- include "sentry.labels" . | nindent 4 }}
{{- include "sentry.selectorLabels" (list $ "ingest") | nindent 4 }}
spec:
replicas: {{ .Values.ingest.replicas }}
selector:
matchLabels:
{{- include "sentry.selectorLabels" (list $ "ingest") | nindent 6 }}
template:
metadata:
labels:
{{- include "sentry.selectorLabels" (list $ "ingest") | nindent 8 }}
spec:
initContainers:
{{- include "sentry.waitForTCP" (list "redpanda" (printf "%s-redpanda" .Release.Name) "9092") | nindent 8 }}
{{- include "sentry.waitForTCP" (list "clickhouse" (printf "%s-clickhouse" .Release.Name) "9000") | nindent 8 }}
containers:
- name: ingest
image: "{{ .Values.ingest.image.repository }}:{{ .Values.ingest.image.tag }}"
imagePullPolicy: {{ .Values.global.imagePullPolicy }}
{{- if and .Values.enterprise.enabled .Values.ingest.requireTenantCredential }}
# -mode=server only: this Deployment stops running the
# ClickHouse-writing consumer half (the default -mode=all)
# once per-tenant write-routing is on -- enterprise-ingest.yaml
# (below) takes over consuming sentry.logs.raw instead, so it
# can write each tenant's records to their own database rather
# than the one shared table ingest's own consumer always
# writes to. The agent-facing server half (PushBatch, tenant
# tagging via TenantResolver) keeps running here unconditionally
# either way -- only which process consumes the topic changes.
args: ["-mode=server"]
{{- end }}
env:
- name: REDPANDA_BROKERS
value: "{{ .Release.Name }}-redpanda:9092"
- name: CLICKHOUSE_ADDR
value: "{{ .Release.Name }}-clickhouse:9000"
- name: CLICKHOUSE_PASSWORD
valueFrom:
secretKeyRef:
name: {{ .Release.Name }}-clickhouse
key: password
{{- if and .Values.enterprise.enabled .Values.ingest.requireTenantCredential }}
# Enables ingest/internal/grpcserver.TenantResolver.
# Deliberately its OWN opt-in, not folded into
# enterprise.enabled directly (same reasoning
# api.yaml/enterprise-api.yaml's ENTERPRISE_AUTH_URL isn't
# set just because enterprise.enabled is true -- see that
# env var's own comment there): turning this on requires
# every agent to already present a valid `Authorization:
# Bearer <ingest token>` (minted via `enterprise-auth
# -create-ingest-credential-tenant=<id>`) or be refused
# outright, which would silently break ingest for any
# not-yet-reconfigured agent if it defaulted on alongside
# enterprise.enabled. Off (the default) leaves every record
# without a tenant_id header, same as every Phase 0-3
# deployment.
- name: ENTERPRISE_AUTH_URL
value: "http://{{ .Release.Name }}-enterprise-auth:8082"
{{- end }}
ports:
- name: grpc
containerPort: 4317
{{- if .Values.ingest.tlsSecretName }}
volumeMounts:
- name: tls
mountPath: /etc/sentry-ingest
readOnly: true
{{- end }}
resources:
{{- toYaml .Values.ingest.resources | nindent 12 }}
{{- if .Values.ingest.tlsSecretName }}
volumes:
- name: tls
secret:
secretName: {{ .Values.ingest.tlsSecretName }}
{{- end }}
---
apiVersion: v1
kind: Service
metadata:
name: {{ .Release.Name }}-ingest
labels:
{{- include "sentry.labels" . | nindent 4 }}
{{- include "sentry.selectorLabels" (list $ "ingest") | nindent 4 }}
spec:
selector:
{{- include "sentry.selectorLabels" (list $ "ingest") | nindent 4 }}
ports:
- name: grpc
port: 4317