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:- Be invited to your ClickHouse Cloud organization. An organization admin invites users from the Cloud console. See Manage cloud users for details.
- 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.
- Cloud Users and roles
- ClickStack Team Settings
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.
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.
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.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
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.
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.
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
containstestingwith access level Read - Tag
istestingwith access level Read