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).
19 lines
859 B
SQL
19 lines
859 B
SQL
-- Correction to a Phase 3 gap found during Phase 4 planning: alert_state
|
|
-- never got a tenant_id column, unlike alert_rules/dashboards/
|
|
-- notification_targets. Backfilled via a join through alert_rules.id
|
|
-- (its owning rule's tenant), not blindly defaulted, even though in
|
|
-- practice every pre-Phase-4 row's rule already belongs to 'default'.
|
|
-- Bundled as one migration (add nullable -> backfill -> enforce NOT
|
|
-- NULL) since it's one logical schema change, same shape as
|
|
-- /storage/migrations/0002_add_record_id.sql bundling an ADD COLUMN
|
|
-- with its index in one file.
|
|
ALTER TABLE alert_state ADD COLUMN IF NOT EXISTS tenant_id TEXT;
|
|
|
|
UPDATE alert_state
|
|
SET tenant_id = alert_rules.tenant_id
|
|
FROM alert_rules
|
|
WHERE alert_state.rule_id = alert_rules.id
|
|
AND alert_state.tenant_id IS NULL;
|
|
|
|
ALTER TABLE alert_state ALTER COLUMN tenant_id SET NOT NULL
|