Skip to main content
ClickStack includes role-based access control (RBAC) so you can define custom roles with fine-grained permissions over dashboards, saved searches, sources, alerts, webhooks, and notebooks. Permissions work at two levels: resource-level access (no access, read, or manage per resource type) and optional fine-grained rules that restrict access to individual resources by name, tag, or ID. ClickStack ships with three built-in roles, and you can create custom roles to match your team’s needs.
Managed ClickStack onlyRBAC is only available in Managed ClickStack deployments.

ClickHouse Cloud users and ClickStack users

ClickStack users sign in with their ClickHouse Cloud accounts, but access is controlled in two places that work independently: In short, the Cloud console decides whether someone can open ClickStack, and ClickStack RBAC decides what they can do once they’re in.

User access prerequisites

Before you can assign ClickStack roles, each user must:
  1. Be invited to your ClickHouse Cloud organization. An organization admin invites users from the Cloud console. See Manage cloud users for details.
  2. Have SQL Console access on the service. Navigate to your service’s Settings → SQL Console Access and set the appropriate permission level:
Once a user has Cloud access and has opened ClickStack, they appear on the ClickStack Team Settings page where you can assign a ClickStack role. To invite or remove users, use Manage in Console on the Team Members card, which opens the Cloud console members page.

When users appear in ClickStack

ClickStack adds a user to its team the first time they open ClickStack from the Cloud console. Until then, they don’t appear in Team Settings, even if they’re already a member of your Cloud organization. That means you can’t give a user a role before they’ve opened ClickStack. When a user opens ClickStack for the first time, they get a role as follows:
  • The first user to open ClickStack for a team becomes a ClickStack Admin. For a ClickHouse Observability instance, opening ClickStack from any of its services counts.
  • Everyone after that gets the team’s default new user role. This is Member unless an Admin has changed it.
To control what new users can do before they sign in, set the default new user role first. For example, set it to ReadOnly, then upgrade specific users after they’ve opened ClickStack.
We’re improving how ClickStack syncs with Cloud organization membership, so users added in the Cloud console will appear in ClickStack without first opening it.

ClickStack roles are separate from Cloud console roles

ClickStack roles and Cloud console roles don’t sync with each other:
  • A Cloud Organization Admin isn’t automatically a ClickStack Admin. Their ClickStack role is whatever they got when they first opened ClickStack, or whatever a ClickStack Admin has set it to since.
  • Changing a user’s role in the Cloud console doesn’t change their ClickStack role, and changing their ClickStack role doesn’t change their Cloud console role.
  • ClickStack roles apply to one team. A ClickHouse Observability instance has a single team shared by all of its services. Any other service you open ClickStack from has its own team. If your organization has more than one ClickStack team, a user can have a different role on each one. Being an Admin on one team doesn’t make them an Admin on another.
Cloud console access still comes first. A user with a ClickStack Admin role can’t open ClickStack if they lose SQL Console access to the service or are removed from the organization.

Removing users

Remove users from the Cloud console. See Remove a user. After that, they can’t sign in to ClickStack. Removing someone from the Cloud organization doesn’t remove them from ClickStack yet. They may still be listed in Team Settings with their last ClickStack role, but they can’t access ClickStack. We’re working on removing these users automatically.
Keep at least one other ClickStack AdminOnly ClickStack Admins can change user roles and the default new user role. Before you remove a user who is a ClickStack Admin from your Cloud organization, make sure another user has the ClickStack Admin role. If no remaining user is a ClickStack Admin, contact ClickHouse support to restore admin access.

Built-in roles

ClickStack includes three system roles. You can’t edit or delete these. The first user to open ClickStack for a team gets the Admin role. Users who join later get the default new user role.

Assigning roles to team members

The Team Settings page lists all team members with their current role. To change a role, click Edit next to the user’s name and select a new role. Each user has exactly one role.

Default new user role

You can set a default role for new users under Security policies. ClickStack gives this role to every user who joins the team by opening ClickStack for the first time, except the first user, who becomes an Admin. If you don’t set a default, new users get the Member role. The default only applies when a user joins. Changing it doesn’t affect existing team members. To change their roles, edit them one at a time on the Team Settings page.

Creating a custom role

1

Navigate to Team Settings

Open Team Settings and scroll to RBAC Roles.
2

Add a new role

Click + Add Role. Enter a Role Name and optionally add a Description.
3

Configure permissions and save

Set permissions for the role, then click Create Role.
Custom roles appear alongside system roles in the RBAC Roles section, with Edit and Delete controls.

Role permissions

Resource permissions

Each role grants an access level per resource type. The three levels are: The resource types you can control are:
  • Dashboards — saved dashboard layouts and charts.
  • Saved searches — persisted log/trace/event queries.
  • Sources — ingestion source configurations.
  • Alerts — alert rules and their notification settings.
  • Webhooks — outbound notification destinations (such as Slack, PagerDuty, and generic HTTP endpoints) that alerts deliver to. This doesn’t refer to the ClickStack API.
  • Notebooks — collaborative investigation notebooks.

Administrative permissions

In addition to resource permissions, each role includes two administrative settings:
  • Users (No Access · Limited Access) — controls whether the role can view team members and their roles. Only Admins can invite, remove, or update users.
  • Team (Read · Manage) — controls whether the role can view or modify team-level settings such as security policies and RBAC configuration.

Fine-grained access rules

Dashboards, Saved Searches, Sources, and Notebooks support fine-grained controls that restrict access to individual resources within a category. Use these when you need to limit a role to specific resources rather than granting blanket access to the entire resource type.

Default access vs. fine-grained controls

Each resource type has an Access Control Mode:
  • Default Access — applies a single access level (No Access, Read, or Manage) to all resources of that type.
  • Fine-Grained Controls — lets you define access rules that match specific resources by condition. Resources that don’t match any rule default to no access.
To switch modes, click the chevron to expand a resource type in the role editor, then toggle the Access Control Mode.

Configuring access rules

Each access rule consists of a condition and an access level. Conditions match resources by their properties: The following screenshot shows both the dashboard ID highlighted in the URL bar and a “TESTING” tag visible in the tag panel (top-right). You can add multiple rules per resource type. Each rule is checked independently using OR logic — a resource is accessible if it matches any rule. Resources that don’t match any rule aren’t accessible. Example: To give a role read-only access to testing dashboards, expand Dashboards, switch to Fine-Grained Controls, and add two rules:
  • Name contains testing with access level Read
  • Tag is testing with access level Read
A dashboard that matches either rule is accessible.

Security policies

The Security Policies section in Team Settings provides additional controls. Default New User Role sets the role ClickStack gives to new users when they first open ClickStack. If you don’t set it, new users get Member. See Default new user role. Generative AI lets you enable or disable LLM-powered features (such as natural language query generation) powered by Anthropic or Amazon Bedrock. When disabled, no data is sent to AI providers.