How finely can Managed ClickStack split access? Per game, per user, per column

A question that comes with every multi-team ClickStack rollout: if each game team (or each person) must see only its own logs, how far down can access be split — dashboards, search and alerts alike? This lab builds one shared log table for three games and tries every layer that decides what a Managed ClickStack user sees: ClickStack roles, the ClickHouse identity ClickStack queries with, row policies, and masking policies.

Verified on 2026-11-07, synthetic data only, in two rounds. Round 1: ClickHouse Cloud 26.8.1.608 (ap-northeast-2), ClickStack UI hyperdx-chc 2.43.1, alert worker hyperdx-chc-alerts 2.42.0, 04:36–04:53 UTC, one ClickStack user (an Admin). Round 2: a new trial organization, ClickHouse Cloud 26.6.1.2455 (ap-northeast-2, one replica), the same ClickStack versions, 05:44–06:33 UTC, two users — the Admin and a test user whose ClickStack role was changed per step, each in its own browser profile. Evidence: system.query_log / system.session_log rows and the screens under images/, summarised in results/2026-11-07-managed.md.

Not run: the objects-id role and the system ReadOnly role on the test user; masking in round 2 (round 1 only); whether the JWT name's hash changes on a new login.

Result

Layer	What can be split	Search	Dashboards	Alerts	Checked how
Cloud console	who may open ClickStack at all (per service: SQL console no access / read only / admin)	—	—	creating alerts needs admin	docs only
ClickStack role — resource level	dashboards, saved searches, sources, webhooks, alerts, notebooks: no access / read / manage	per source	read-only dashboards ("You have read-only access")	no access hides the menu, /alerts says "You do not have permission to view alerts"	test user, round 2
ClickStack role — fine-grained	dashboards, saved searches, sources by name, tag or ID (is / contains), OR-ed rules	rows are not restricted: the allowed source still returned bravo rows	only the tagged dashboard listed; another by URL: "Dashboard Not Available"	no per-alert rule	test user, round 2
ClickStack role — custom, without Team read	—	the whole app: Unauthorized	same	same	test user, round 2
ClickStack role — row condition	integration: clickhouse, per connection + table, where in SQL or Lucene	—	—	—	the API stores it (beta), the editor has no section for it, and an Admin cannot assign it: Not allowed to assign a role with privileges exceeding your own
ClickHouse row policy on a role	TO sql_console_admin, sql_console_read_only	no effect	no effect	no effect	ClickStack's session has roles = [] (round 1)
ClickHouse row policy, blanket	TO ALL EXCEPT default	filtered	filtered (SQL tiles too)	filtered (the alert worker is in ALL)	used_row_policies on every query (round 1)
ClickHouse row policy, per user	TO \JWT::…::``	that user only: alpha 7,036 rows vs the Admin's 21,109	same	alerts not filtered: the restricted user still sees every alert and its history	two users, round 2
Per-user policy, console SQL editor	same policy	—	—	—	round 2 service: the editor runs as the same JWT user, alpha only; round 1 service: as sql-console
Alert worker left out	… EXCEPT default, \hdx-alert-internal``	filtered	filtered	sees everything: an alert fires on rows its viewer cannot search	round 1
Masking, String column	UPDATE Body = replaceRegexpAll(…)	masked	masked	—	WHERE on the original value: 0 rows (round 1)
Masking, Map key	UPDATE LogAttributes = mapUpdate(…)	row detail masked, the LogAttributes['client.ip'] column is not	same	—	subcolumn read skips the mask; WHERE on the original still matches 57,920 rows (round 1)
Masking with a lambda	mapApply((k, v) -> …)	every query fails	fails	—	There is no column k in table (round 1)

What this means:

1. ClickStack roles split screens, not data. A tag rule hid the other games' dashboards from the list and by URL, but the same user, searching the one source it could read, got bravo's rows. Splitting data per game needs one of the database layers below.
2. Role row conditions are not usable yet. The Cloud API accepts and stores them, but the role editor does not show them and the Admin's attempt to give such a role to a user was refused.
3. Row policies work, per user too — through the JWT identity, not roles. Search and dashboard queries run as a per-user JWT::…<email>::<hash> user with no roles; alert queries run as one shared user (hdx-alert-internal / hyperdx-alert-internal, role hdx_alert_role). A policy on the SQL console roles never reached ClickStack; a policy naming one JWT user restricted exactly that user — side by side, the test user saw alpha only while the Admin saw all three games. On the round 2 service the console SQL editor ran as the same JWT user and was restricted too. The JWT name exists only after the user's first login (UNKNOWN_ROLE before) and its form differs between services (round 2 adds the service ID).
4. Alerts have one scope for the whole team. The alert worker is one user, so a per-user policy never applies to alerts: the test user restricted to alpha still listed every alert, saw charlie firing and its history. A blanket policy that includes the alert worker filters every alert alike; leaving the worker out lets alerts see everything.
5. Write per-user policies as an allowlist. A user with no policy is not restricted by the others — the Admin above saw everything. Start from a blanket policy that grants nothing sensitive, then add one policy per person or team.
6. Mask String columns, not Map keys. A masked String column stayed masked in results and in WHERE. A masked Map key was masked only where the whole map was read. A lambda in the masking expression breaks every query of the user it applies to.
7. Give every custom role Team read. Without it the user's ClickStack is one Unauthorized page. A custom role can never hold manage on users, and manage all is refused, so only the system Admin role re-roles people. Roles are team-wide (the same role IDs on two services of one organization); sources and dashboards are per service.

Roadmap (public statements, read 2026-11-07)

• The RBAC announcement (2026-04-01) says row-based access control is planned and that roles will be able to carry filtering conditions.
• The Cloud OpenAPI (read 2026-11-07) already has that shape on POST …/clickstack/roles: a permission with integration: clickhouse and conditions: {connection, from: {databaseName, tableName}, where, whereLanguage}, described as "row-level access", endpoint marked beta. On 2026-11-07 the role editor did not show it and an Admin could not assign such a role.

Run it

Needs a ClickHouse Cloud service with ClickStack, its default password and an org API key. For the second-user checks, a second login in its own browser profile and a ClickStack Admin to change its role in Team Settings.

python3 bin/lab.py setup            # table, 172,800 rows over 24 h, source, saved searches, dashboards, alerts
python3 bin/lab.py feed 60          # fresh rows every 30 s, so alerts have data
python3 bin/lab.py role all         # the scenario roles (not assigned to anyone)
# apply the statements in sql/policies.sql one step at a time; after each, run a fresh search
python3 bin/lab.py probe 5          # what ClickStack and the alert worker ran, as whom, with which policies
python3 bin/lab.py alerts           # alert states
python3 bin/lab.py cleanup          # alerts, dashboards, saved searches, webhook, source, database
python3 bin/lab.py drop-role        # then delete the scenario roles in Team Settings

Add --ch-env <file> --api-env <file> for another service. sql/schema.sql — the table (ClickStack's otel_logs columns plus Game and Env, sorted by game and environment first). sql/rows.sql — synthetic rows: three games, prod 80 % / qa 20 %, three services each, 200 players, 5 % ERROR. bin/lab.py — the ClickStack objects and the scenario roles through the Cloud API (/clickstack/sources, /saved-searches, /dashboards, /alerts, /webhooks, /roles).

Screens

Round 1 (one Admin user, Seoul service):

01 — before any policy: alpha, bravo, charlie	02 — a tag rule set through the API, shown by the role editor
03 — the same role: no section for its row condition	04 — TO ALL EXCEPT default: alpha only
05 — plus a policy on this user's JWT identity: alpha + bravo	06 — an SQL tile with no WHERE, same policies: no charlie
07 — alert worker inside the policy: bravo and charlie OK	09 — alert worker excluded: bravo and charlie fire
08 — a lambda in a masking policy breaks the search	10 — row detail masked, the client.ip column not
11 — a policy on the SQL console roles: all three games still

Round 2 (Admin and test user, trial organization):

r2-11 — a role with a row condition: "Not allowed to assign a role with privileges exceeding your own"	r2-02 — a custom role without Team read: the app is one Unauthorized
r2-03 — resource level read: no Alerts menu, read-only dashboard	r2-05 — Alerts no access: "You do not have permission to view alerts"
r2-06 — tag rule game:alpha: one dashboard listed	r2-07 — the bravo dashboard by URL: "Dashboard Not Available"
r2-08 — same user, same role: Game:"bravo" returns 7,039 rows	r2-09 — per-user row policy: the test user sees alpha only (7,036)
r2-10 — same range, the Admin: three games (21,109)	r2-12 — the restricted user still sees every alert; charlie firing
r2-13 — and cannot search charlie's errors: 0 rows	r2-14 — console SQL editor as the same user: alpha only, via the JWT identity

---