Phase 4: SSO scaffolding, RBAC enforcement, tenant-scoped dashboards, audit logging, K8s deployment
RBAC (api/internal/authz) is live on /query and /dashboards, backed by a new enterprise/ module (session issuance, audit logging, RBAC storage, OIDC/SAML protocol wiring) that core never imports -- only calls over HTTP. Found and fixed a real cross-tenant vulnerability in dashboards (no tenant_id filtering at all) while writing the threat model doc. Two things are explicitly NOT done, documented rather than hidden: tenant isolation for log data itself (/query still shares one ClickHouse connection and Tantivy index across every tenant -- RBAC controls who can query, not what a query can see), and human SSO login (protocol wiring exists, no HTTP handler calls it yet). See docs/security/threat-model.md and docs/phase-4-runbook.md. Also adds deploy/ (Go Operator + Helm chart, validated offline only -- no cluster was reachable in this environment).
This commit is contained in:
@@ -0,0 +1,180 @@
|
||||
# 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
|
||||
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: []
|
||||
Reference in New Issue
Block a user