jcoffey-dev
3eb0f4c589
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).
56 lines
2.2 KiB
Smarty
56 lines
2.2 KiB
Smarty
{{/*
|
|
Standard labels applied to every resource this chart renders.
|
|
*/}}
|
|
{{- define "sentry.labels" -}}
|
|
app.kubernetes.io/part-of: sentry
|
|
app.kubernetes.io/managed-by: {{ .Release.Service }}
|
|
helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version }}
|
|
{{- end -}}
|
|
|
|
{{/*
|
|
Per-component selector labels -- usage:
|
|
{{ include "sentry.selectorLabels" (list $ "api") }}
|
|
A plain string arg (the old shape this started with) can't reach
|
|
$.Release from inside the defined template -- `include`'s argument
|
|
becomes the template's entire root context, so a bare "api" string
|
|
leaves no way to get back to the chart root. A two-element list carries
|
|
both.
|
|
*/}}
|
|
{{- define "sentry.selectorLabels" -}}
|
|
{{- $root := index . 0 -}}
|
|
{{- $name := index . 1 -}}
|
|
app.kubernetes.io/name: sentry-{{ $name }}
|
|
app.kubernetes.io/instance: {{ $root.Release.Name }}
|
|
{{- end -}}
|
|
|
|
{{/*
|
|
An initContainer that busy-waits for a TCP host:port to accept
|
|
connections -- usage: {{ include "sentry.waitForTCP" (list "name-suffix" "host" "port") }}
|
|
|
|
This approximates docker-compose.yml's `depends_on: condition:
|
|
service_healthy` (waits for the dependency's process to be reachable),
|
|
but NOT `condition: service_completed_successfully` (waits for a
|
|
one-shot Job, like clickhouse-migrate, to have actually finished). That
|
|
second guarantee doesn't have a lightweight equivalent here without
|
|
giving every app pod's ServiceAccount RBAC to read Job status, which is
|
|
a lot of privilege for a startup-ordering nicety -- see
|
|
deploy/helm/sentry/README.md's "Startup ordering" section. The gap it
|
|
leaves (a pod starts before its migration Job has finished) is covered
|
|
by the app's own crash-and-restart-on-connect/schema failure: every Go
|
|
service here already os.Exit(1)s on a failed Postgres/ClickHouse ping at
|
|
startup (see e.g. api/cmd/api/main.go), so Kubernetes' restart policy
|
|
naturally retries until the schema is ready. Documented as a real,
|
|
accepted tradeoff, not implied to be a hard ordering guarantee.
|
|
*/}}
|
|
{{- define "sentry.waitForTCP" -}}
|
|
{{- $name := index . 0 -}}
|
|
{{- $host := index . 1 -}}
|
|
{{- $port := index . 2 -}}
|
|
- name: wait-for-{{ $name }}
|
|
image: busybox:1.36
|
|
command:
|
|
- sh
|
|
- -c
|
|
- until nc -z -w2 {{ $host }} {{ $port }}; do echo "waiting for {{ $host }}:{{ $port }}"; sleep 2; done
|
|
{{- end -}}
|