Files
cairnobs/deploy/helm/sentry/values.yaml
T
jcoffey-dev 3037b31b0f Phase 4: Helm chart enforces api vs enterprise-api, closing the deployment-topology gap
deploy/helm/sentry/templates/api.yaml and the new enterprise-api.yaml
are mutually exclusive, gated on opposite sides of the same
enterprise.enabled flag -- exactly one renders, both as a Deployment+
Service named {{ .Release.Name }}-api on port 8080, so every consumer
(alerting's API_QUERY_URL, web's build args) needs zero conditional
logic of its own. This is the concrete fix for what the threat model
named as the single largest remaining gap once both storage engines'
isolation mechanisms were built: previously nothing forced or flagged
whether a deployment ran the tenant-isolated binary. Now the same flag
that turns on RBAC/audit/SSO also chooses the query binary.

Verified by parsing (not eyeballing) helm template's rendered output
under both value sets: exactly one sentry-api Deployment/Service either
way, with the right image, and kubeconform -strict clean against the
real Kubernetes 1.31 schema. Not applied to a live cluster (still no
cluster in this environment) -- docker-compose.yml also still runs
plain api unconditionally, so this enforcement is Helm-only for now.

Updated the threat model, architecture doc, CLAUDE.md, and deploy/
READMEs to reflect this and to name what's left: ingest has no tenant
concept for either storage engine (undesigned), and the Tenant CRD
(deploy/operator) and enterprise-api -provision-tenant are still two
separate, unreconciled provisioning mechanisms.
2026-08-14 06:20:20 -07:00

190 lines
6.5 KiB
YAML

# Default values for the sentry chart. See deploy/helm/sentry/README.md
# for the multi-tenant-specific values (enterprise.*, tenants) and what
# "multi-tenant-aware" does and doesn't mean at this layer.
#
# Image repositories default to locally-built tags matching each
# service's docker-compose.yml container_name, minus the "sentry-"
# container_name prefix duplication -- push these to a registry this
# cluster can actually pull from before installing; this chart never
# builds images itself (same division of labor as docker-compose.yml:
# `docker compose build` vs. `docker compose up`).
global:
imagePullPolicy: IfNotPresent
redpanda:
image:
repository: docker.redpanda.com/redpandadata/redpanda
tag: v24.2.7
persistence:
size: 10Gi
resources: {}
# Built from ./transport (docker-compose.yml's redpanda-provision
# service) -- the one-shot topic-creation Job below.
provisionImage:
repository: sentry-redpanda-provision
tag: latest
clickhouse:
image:
repository: clickhouse/clickhouse-server
tag: "24.8"
persistence:
size: 20Gi
resources: {}
# Leave empty to auto-generate and persist across upgrades -- see
# templates/secrets.yaml's stableSecretValue helper.
password: ""
# Built from ./storage (docker-compose.yml's clickhouse-migrate
# service) -- the one-shot schema-migration Job.
migrateImage:
repository: sentry-clickhouse-migrate
tag: latest
postgres:
image:
repository: postgres
tag: 16-alpine
persistence:
size: 10Gi
resources: {}
password: ""
auditWriterPassword: ""
# Built from ./metadata (docker-compose.yml's metadata-migrate
# service) -- the one-shot schema-migration Job.
migrateImage:
repository: sentry-metadata-migrate
tag: latest
ingest:
image:
repository: sentry-ingest
tag: latest
replicas: 1
resources: {}
# mTLS server cert/key/CA -- see hack/dev-certs/generate.sh for the
# dev equivalent of what this Secret must contain
# (server.pem/server-key.pem/ca.pem) in a real deployment. Unlike
# docker-compose.yml's bind-mounted ./hack/dev-certs/out, a cluster
# deployment supplies this as a real Secret -- named here, not
# generated by this chart (cert issuance is out of scope, same
# "boring, well-understood" preference as everywhere else in this
# repo -- use cert-manager or an equivalent, don't hand-roll it here).
tlsSecretName: ""
search:
image:
repository: sentry-search
tag: latest
# Pinned to 1: search consumes the same Redpanda topic ingest's
# consumer does with its own offset tracking (see search/README.md).
# A second replica would form a second, independent consumer instance
# against the same partitions with no coordination -- correctness,
# not just resource waste, is the reason this isn't a `replicas` knob
# yet. Matches CLAUDE.md's Phase 4 non-goal: "no general multi-cluster
# orchestration."
replicas: 1
resources: {}
persistence:
size: 20Gi
api:
image:
repository: sentry-api
tag: latest
replicas: 2
resources: {}
alerting:
image:
repository: sentry-alerting
tag: latest
# Pinned to 1 for the same reason as search: rulestore.ClaimDueRules
# has no leader-election/partitioning story for multiple evaluator
# replicas yet -- two would both try to claim and evaluate the same
# due rules. Named explicitly rather than silently defaulted, since
# it's the kind of knob someone reasonably expects to just work.
replicas: 1
resources: {}
# See templates/alerting.yaml's comment -- only meaningful when
# enterprise.enabled is true. Empty by default.
apiServiceToken: ""
web:
image:
repository: sentry-web
tag: latest
replicas: 2
resources: {}
# NOT wired to any Deployment env var -- web is a static SvelteKit
# build (adapter-static, see web/package.json), and VITE_API_BASE_URL/
# VITE_ALERTING_API_BASE_URL/VITE_ENTERPRISE_AUTH_BASE_URL are baked in
# at *image build time* (docker-compose.yml's web.build.args), not
# read at container runtime. Deploying this chart into a real cluster
# means rebuilding the web image with these three build args pointed
# at wherever api/alerting/enterprise-auth are actually reachable from
# a browser (an Ingress host, a LoadBalancer IP, etc.) -- this section
# exists to document that requirement, not because the chart can act
# on it.
builtWithApiBaseURL: "http://localhost:8080"
builtWithAlertingApiBaseURL: "http://localhost:8081"
builtWithEnterpriseAuthBaseURL: "http://localhost:8082"
# enterprise-auth (commercial license) + the tenant-operator that
# reconciles the Tenant CRD -- both off by default, matching
# docker-compose.yml's own "included, not wired into enforcement by
# default" stance (see its enterprise-auth service comment) and
# enterprise/README.md's "Status" section on what's built vs. deferred.
enterprise:
enabled: false
image:
repository: sentry-enterprise-auth
tag: latest
# enterprise-api (templates/enterprise-api.yaml) -- swaps in for
# api.yaml's plain api Deployment when enterprise.enabled is true, on
# the same Service/port every consumer already expects. Built from the
# repo root (needs api/ and proto/, not just enterprise/), unlike
# enterprise-auth's image above -- see
# enterprise/cmd/enterprise-api/Dockerfile.
apiImage:
repository: sentry-enterprise-api
tag: latest
replicas: 1
resources: {}
# Leave empty to auto-generate (>= 32 bytes) and persist across
# upgrades -- see templates/secrets.yaml.
sessionSigningKey: ""
oidc:
issuerURL: ""
clientID: ""
clientSecret: ""
redirectURL: ""
saml:
entityID: ""
acsURL: ""
idpMetadataURL: ""
# Installs deploy/operator (the Tenant CRD controller) alongside this
# chart. Only meaningful when enterprise.enabled is also true --
# gated on that, not a separate flag, since a Tenant CR with no
# enterprise-auth deployed to consume its Secret has nothing to do.
tenantOperator:
enabled: false
image:
repository: sentry-tenant-operator
tag: latest
resources: {}
# One entry per tenant to provision -- rendered as Tenant CRs
# (templates/tenants.yaml), reconciled by the tenant-operator into a
# per-tenant ClickHouse credential Secret. See
# deploy/operator/internal/controller/tenant_controller.go's doc comment
# for exactly what that does and doesn't set up. Empty by default; a
# real two-tenant deployment (Phase 4's exit criteria) sets e.g.:
# tenants:
# - name: acme
# displayName: "Acme Corp"
# - name: globex
# displayName: "Globex Corporation"
tenants: []