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:
+42
-1
@@ -11,11 +11,14 @@ doesn't provide.
|
||||
|
||||
## Schema
|
||||
|
||||
Six tables across two features, one shared database (`sentry_metadata`):
|
||||
Seven tables across three features, one shared database (`sentry_metadata`):
|
||||
|
||||
- `dashboards`, `dashboard_panels` — owned by `/api` (`api/internal/dashboards`)
|
||||
- `notification_targets`, `alert_rules`, `alert_state`, `delivery_log` —
|
||||
owned by `/alerting`
|
||||
- `audit_log` — owned by `enterprise/internal/audit` (Phase 4). Unlike
|
||||
every other table here, this one is **not** written through the shared
|
||||
`sentry` role/pool — see "The `audit_writer` role" below.
|
||||
|
||||
"Owned" here is a documentation convention, not a technical boundary —
|
||||
both services connect to the same Postgres instance/database, each with
|
||||
@@ -24,6 +27,43 @@ shared across service `internal/` trees for this, matching the existing
|
||||
repo convention that only `/proto` is shared code (and even that isn't
|
||||
shared logic, just generated bindings).
|
||||
|
||||
## The `audit_writer` role: a second, more restricted credential
|
||||
|
||||
`audit_log` is append-only by design (see
|
||||
`/docs/phase-4-isolation-design.md`'s audit-logging section) — a
|
||||
compliance requirement, not just a convention, so it's backed by two
|
||||
independent defenses, both verified against a live Postgres, not just
|
||||
written:
|
||||
|
||||
1. A dedicated `audit_writer` Postgres role (`migrations/0012`-`0014`)
|
||||
with **only** `INSERT`/`SELECT` grants on `audit_log` — no
|
||||
`UPDATE`/`DELETE`/`TRUNCATE`, ever. `enterprise/internal/audit.Store`
|
||||
connects using this role's credentials via its **own** `pgxpool.Pool`,
|
||||
never the shared `sentry` pool `api`/`alerting`'s other stores use —
|
||||
reusing the shared pool for audit writes would give audit_log's
|
||||
application-level credential the same `UPDATE`/`DELETE` grants every
|
||||
other metadata table has, silently defeating the whole point.
|
||||
2. A `BEFORE UPDATE OR DELETE` trigger (`migrations/0015`-`0016`) that
|
||||
rejects the operation for **any** role, including the table owner
|
||||
(`sentry`) — confirmed live: even `sentry` needs to explicitly
|
||||
`ALTER TABLE audit_log DISABLE TRIGGER audit_log_immutable` (a
|
||||
privileged, distinct-from-normal-access operation) before it can
|
||||
modify a row. This is redundant defense-in-depth independent of the
|
||||
grant, protecting against a future migration accidentally re-granting
|
||||
`UPDATE` to `audit_writer`.
|
||||
|
||||
`AUDIT_WRITER_PASSWORD` (default `audit-writer-dev-only`, matching every
|
||||
other dev-only credential in this repo) sets the role's password at
|
||||
creation time via `psql -v audit_writer_password=...` substitution in
|
||||
`migrate.sh` — **not** hardcoded in the migration SQL file itself. One
|
||||
real gotcha found while building this: psql's `:'var'` substitution does
|
||||
**not** apply inside a `DO $$ ... $$` dollar-quoted block (by design, so
|
||||
client-side substitution can't corrupt a function/procedure body) — the
|
||||
role-creation migration is a plain `CREATE ROLE`, not wrapped in an
|
||||
`IF NOT EXISTS` check, relying on `schema_migrations` tracking for
|
||||
idempotency instead (the same pattern Phase 1's non-idempotent
|
||||
`ALTER TABLE ... ADD COLUMN` migration in `/storage` already used).
|
||||
|
||||
## Migration tooling: mirrors `/storage/migrate.sh`, not a framework
|
||||
|
||||
Same reasoning as `/storage/README.md`: pulling in `golang-migrate` for
|
||||
@@ -52,6 +92,7 @@ Environment variables `migrate.sh` reads (all optional except
|
||||
| `POSTGRES_USER` | `sentry` |
|
||||
| `POSTGRES_PASSWORD` | (empty — must be set) |
|
||||
| `POSTGRES_DATABASE` | `sentry_metadata` |
|
||||
| `AUDIT_WRITER_PASSWORD` | `audit-writer-dev-only` |
|
||||
|
||||
The database itself isn't created by `migrate.sh` — the `postgres:16-alpine`
|
||||
image auto-creates `POSTGRES_DB` on first startup, unlike ClickHouse where
|
||||
|
||||
+9
-1
@@ -11,6 +11,13 @@ POSTGRES_PORT="${POSTGRES_PORT:-5432}"
|
||||
POSTGRES_USER="${POSTGRES_USER:-sentry}"
|
||||
POSTGRES_PASSWORD="${POSTGRES_PASSWORD:-}"
|
||||
POSTGRES_DATABASE="${POSTGRES_DATABASE:-sentry_metadata}"
|
||||
# Password for the restricted audit-log-writer Postgres role (Phase 4
|
||||
# task 4, see /docs/phase-4-isolation-design.md's audit logging
|
||||
# section) -- a second, narrower-granted role, not the shared
|
||||
# POSTGRES_PASSWORD above. Passed to psql via -v so the migration SQL
|
||||
# file can reference it as :'audit_writer_password' without ever
|
||||
# hardcoding a credential in a file checked into git.
|
||||
AUDIT_WRITER_PASSWORD="${AUDIT_WRITER_PASSWORD:-audit-writer-dev-only}"
|
||||
|
||||
export PGPASSWORD="$POSTGRES_PASSWORD"
|
||||
|
||||
@@ -18,7 +25,8 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
MIGRATIONS_DIR="${SCRIPT_DIR}/migrations"
|
||||
|
||||
psql_exec() {
|
||||
psql -v ON_ERROR_STOP=1 -X -q -h "$POSTGRES_HOST" -p "$POSTGRES_PORT" -U "$POSTGRES_USER" -d "$POSTGRES_DATABASE" "$@"
|
||||
psql -v ON_ERROR_STOP=1 -X -q -h "$POSTGRES_HOST" -p "$POSTGRES_PORT" -U "$POSTGRES_USER" -d "$POSTGRES_DATABASE" \
|
||||
-v audit_writer_password="$AUDIT_WRITER_PASSWORD" "$@"
|
||||
}
|
||||
|
||||
echo "Ensuring schema_migrations table exists..."
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
CREATE TABLE IF NOT EXISTS audit_log
|
||||
(
|
||||
id BIGSERIAL PRIMARY KEY,
|
||||
tenant_id TEXT NOT NULL,
|
||||
user_id UUID,
|
||||
source TEXT NOT NULL CHECK (source IN ('api', 'web', 'cli', 'alerting')),
|
||||
event_type TEXT NOT NULL CHECK (event_type IN ('query', 'role_change', 'grant_change', 'sso_config_change', 'secret_reveal')),
|
||||
query_text TEXT,
|
||||
row_count INT,
|
||||
duration_ms INT,
|
||||
status TEXT NOT NULL CHECK (status IN ('success', 'error')),
|
||||
error_message TEXT,
|
||||
detail JSONB NOT NULL DEFAULT '{}',
|
||||
prev_hash TEXT,
|
||||
row_hash TEXT NOT NULL,
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
|
||||
)
|
||||
@@ -0,0 +1 @@
|
||||
CREATE INDEX IF NOT EXISTS audit_log_tenant_created_at_idx ON audit_log (tenant_id, created_at DESC)
|
||||
@@ -0,0 +1 @@
|
||||
CREATE ROLE audit_writer LOGIN PASSWORD :'audit_writer_password'
|
||||
@@ -0,0 +1 @@
|
||||
GRANT INSERT, SELECT ON audit_log TO audit_writer
|
||||
@@ -0,0 +1 @@
|
||||
GRANT USAGE ON SEQUENCE audit_log_id_seq TO audit_writer
|
||||
@@ -0,0 +1,5 @@
|
||||
CREATE OR REPLACE FUNCTION audit_log_deny_update_delete() RETURNS TRIGGER AS $$
|
||||
BEGIN
|
||||
RAISE EXCEPTION 'audit_log is append-only: % is not permitted', TG_OP;
|
||||
END
|
||||
$$ LANGUAGE plpgsql
|
||||
@@ -0,0 +1,3 @@
|
||||
CREATE TRIGGER audit_log_immutable
|
||||
BEFORE UPDATE OR DELETE ON audit_log
|
||||
FOR EACH ROW EXECUTE FUNCTION audit_log_deny_update_delete()
|
||||
@@ -0,0 +1,13 @@
|
||||
CREATE TABLE IF NOT EXISTS users
|
||||
(
|
||||
id UUID PRIMARY KEY,
|
||||
email TEXT NOT NULL UNIQUE,
|
||||
display_name TEXT NOT NULL DEFAULT '',
|
||||
-- Set on first successful SSO login (OIDC "sub" or SAML NameID) --
|
||||
-- nullable because a user row can exist before their first login in
|
||||
-- principle (e.g. pre-provisioned by an Admin), though Phase 4's
|
||||
-- baseline flow always creates the row and the SSO subject together.
|
||||
sso_subject TEXT,
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
|
||||
)
|
||||
@@ -0,0 +1,17 @@
|
||||
CREATE TABLE IF NOT EXISTS tenants
|
||||
(
|
||||
id TEXT PRIMARY KEY,
|
||||
display_name TEXT NOT NULL,
|
||||
-- Provisioning state machine from /docs/phase-4-isolation-design.md:
|
||||
-- every tenant-resolution path must refuse to serve a tenant not in
|
||||
-- 'active' state, checked server-side against this column.
|
||||
status TEXT NOT NULL DEFAULT 'provisioning'
|
||||
CHECK (status IN ('provisioning', 'active', 'suspended', 'deprovisioning')),
|
||||
clickhouse_database_name TEXT,
|
||||
tantivy_index_path TEXT,
|
||||
-- Nullable until the first Owner exists -- a tenant can be created
|
||||
-- (provisioning) before any user has logged in to claim ownership.
|
||||
owner_user_id UUID REFERENCES users(id),
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
|
||||
)
|
||||
@@ -0,0 +1,8 @@
|
||||
-- Every Phase 0-3 row (dashboards, alert_rules, notification_targets --
|
||||
-- see their tenant_id DEFAULT 'default' columns) belongs to this tenant.
|
||||
-- Marked 'active' immediately: this data already exists and is already
|
||||
-- being served, unlike a genuinely new tenant that must pass through
|
||||
-- provisioning first.
|
||||
INSERT INTO tenants (id, display_name, status)
|
||||
VALUES ('default', 'Default', 'active')
|
||||
ON CONFLICT (id) DO NOTHING
|
||||
@@ -0,0 +1,14 @@
|
||||
-- A user's role is per-tenant, not global -- see
|
||||
-- /docs/phase-4-rbac-design.md's role matrix (Viewer/Editor/Admin/Owner).
|
||||
-- One row per (tenant, user); a user with no row for a tenant has no
|
||||
-- access to it at all (default-deny, not default-viewer).
|
||||
CREATE TABLE IF NOT EXISTS tenant_memberships
|
||||
(
|
||||
id UUID PRIMARY KEY,
|
||||
tenant_id TEXT NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
|
||||
user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
|
||||
role TEXT NOT NULL CHECK (role IN ('viewer', 'editor', 'admin', 'owner')),
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
UNIQUE (tenant_id, user_id)
|
||||
)
|
||||
@@ -0,0 +1,4 @@
|
||||
-- Supports "which tenants does this user belong to" (session/authorize
|
||||
-- lookups), the reverse direction from the UNIQUE(tenant_id, user_id)
|
||||
-- constraint's own index.
|
||||
CREATE INDEX IF NOT EXISTS idx_tenant_memberships_user_id ON tenant_memberships (user_id)
|
||||
@@ -0,0 +1,18 @@
|
||||
-- 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
|
||||
@@ -0,0 +1,10 @@
|
||||
-- Same gap and same fix as 0022, for delivery_log.
|
||||
ALTER TABLE delivery_log ADD COLUMN IF NOT EXISTS tenant_id TEXT;
|
||||
|
||||
UPDATE delivery_log
|
||||
SET tenant_id = alert_rules.tenant_id
|
||||
FROM alert_rules
|
||||
WHERE delivery_log.rule_id = alert_rules.id
|
||||
AND delivery_log.tenant_id IS NULL;
|
||||
|
||||
ALTER TABLE delivery_log ALTER COLUMN tenant_id SET NOT NULL
|
||||
@@ -0,0 +1,14 @@
|
||||
-- Additive-only per-resource grant: lets a specific user exceed their
|
||||
-- tenant-baseline role on one dashboard (e.g. an Editor granted Admin on
|
||||
-- a dashboard they don't own). No deny-overrides -- named non-goal in
|
||||
-- /docs/phase-4-rbac-design.md and CLAUDE.md's Phase 4 exit criteria.
|
||||
CREATE TABLE IF NOT EXISTS dashboard_permissions
|
||||
(
|
||||
id UUID PRIMARY KEY,
|
||||
dashboard_id UUID NOT NULL REFERENCES dashboards(id) ON DELETE CASCADE,
|
||||
user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
|
||||
role TEXT NOT NULL CHECK (role IN ('viewer', 'editor', 'admin')),
|
||||
granted_by UUID REFERENCES users(id),
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
UNIQUE (dashboard_id, user_id)
|
||||
)
|
||||
@@ -0,0 +1,14 @@
|
||||
-- Extension point named in /docs/phase-4-rbac-design.md: one row
|
||||
-- per-tenant today (each tenant has exactly one ClickHouse database +
|
||||
-- one Tantivy index), not pretending multiple sources per tenant exist
|
||||
-- yet -- that's real future work, this table just leaves room for it.
|
||||
CREATE TABLE IF NOT EXISTS data_sources
|
||||
(
|
||||
id UUID PRIMARY KEY,
|
||||
tenant_id TEXT NOT NULL REFERENCES tenants(id),
|
||||
name TEXT NOT NULL,
|
||||
clickhouse_database_name TEXT NOT NULL,
|
||||
tantivy_index_path TEXT NOT NULL,
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
UNIQUE (tenant_id, name)
|
||||
)
|
||||
@@ -0,0 +1,7 @@
|
||||
-- The 'default' tenant's single data source, pointing at the one
|
||||
-- ClickHouse database ("sentry") and Tantivy index every Phase 0-3
|
||||
-- deployment already uses -- see api/internal/config's CLICKHOUSE_DATABASE
|
||||
-- default and search's index path default.
|
||||
INSERT INTO data_sources (id, tenant_id, name, clickhouse_database_name, tantivy_index_path)
|
||||
SELECT '00000000-0000-0000-0000-000000000001', 'default', 'default', 'sentry', '/var/lib/sentry-search'
|
||||
WHERE NOT EXISTS (SELECT 1 FROM data_sources WHERE tenant_id = 'default')
|
||||
@@ -0,0 +1 @@
|
||||
ALTER TABLE dashboards ADD CONSTRAINT fk_dashboards_tenant FOREIGN KEY (tenant_id) REFERENCES tenants(id)
|
||||
@@ -0,0 +1 @@
|
||||
ALTER TABLE alert_rules ADD CONSTRAINT fk_alert_rules_tenant FOREIGN KEY (tenant_id) REFERENCES tenants(id)
|
||||
@@ -0,0 +1 @@
|
||||
ALTER TABLE notification_targets ADD CONSTRAINT fk_notification_targets_tenant FOREIGN KEY (tenant_id) REFERENCES tenants(id)
|
||||
@@ -0,0 +1 @@
|
||||
ALTER TABLE alert_state ADD CONSTRAINT fk_alert_state_tenant FOREIGN KEY (tenant_id) REFERENCES tenants(id)
|
||||
@@ -0,0 +1 @@
|
||||
ALTER TABLE delivery_log ADD CONSTRAINT fk_delivery_log_tenant FOREIGN KEY (tenant_id) REFERENCES tenants(id)
|
||||
Reference in New Issue
Block a user