Roles
Define and manage access-control Roles and Policies
The Roles/Policies model exists in parallel with a more flexible Members/Permissions model, which will eventually replace it. Cross-compatible Default Roles and Default Policies support customers who still choose to configure Local Users with Roles and Policies. Your configured Local Users appear interchangeably in the new Members UI, and vice versa.
See Which Access Method Should I Use? for detailed differences between the two access control systems.
Availability
Role-based access control is available only on distributed deployments (Stream, Edge) with an Enterprise license tier.
On single-instance deployments or distributed deployments with other licenses all users will have full administrative privileges.
Known Issue
Existing Local Users display in Settings > Global > Members and Teams with the
No Access
Permission even if they’ve been assigned a higher Role. This is a display-only bug: These users’ original Roles still function as configured. For details and fix progress, please see Known Issues.
RBAC Concepts
Cribl Edge’s RBAC mechanism is designed around the following concepts, which you manage in the UI:
Roles: Logical entities that are associated with one or multiple Policies (groups of permissions). You use each Role to consistently apply these permissions to multiple Cribl Edge users.
Policies: A set of permissions. A Role that is granted a given Policy can access, or perform an action on, a specified Cribl Edge object or objects.
Permissions: Access rights to navigate to, view, change, or delete specified objects in Cribl Edge.
Users: You map Roles to Cribl Edge users in the same way that you map user groups to users in LDAP and other common access-control frameworks.
Users are independent Cribl Edge objects that you can configure even without RBAC enabled. For details, see Local Users.
Cribl Edge Roles can be integrated with external authorization/IAM mechanisms, such as LDAP and OIDC and mapped to their respective groups, tags, etc.
Using Roles
Cribl Edge ships with a set of default Roles, which you can supplement.
Default Roles
These Roles ship with Cribl Edge by default.
Organization-Level Roles
Note that some of the Roles below have no counterpart Permission in Cribl’s newer Members/Permissions model.
Name | Description | Permission Equivalent |
---|---|---|
admin | Superuser – authorized to do anything in the system. | Organization Admin |
gitops | Ability to sync the Cribl Edge deployment to a remote Git repository. | N/A |
notification_admin | Read/write access to all Notifications. | N/A |
user | Default Role that gets only a home/landing page to authenticate. This is a fallback for users who have not yet been assigned a higher Role by an admin. | Organization User |
project_user | Read/write access to the simplified Stream Projects UI and related data Subscriptions. Deprecated as of v.4.2. Instead assign Editor, as the most comparable new Project-level Permission. The more-permissive Maintainer, and the more-restrictive Read Only, are also available Permissions. | Project Editor |
Stream Roles
Name | Description | Permission Equivalent |
---|---|---|
stream_user | Basic Role for Stream. | Stream User. |
stream_reader | Allows viewing all Members, Worker Groups, Settings, Leader commits, and legacy Local Users and Roles, with no configuration capabilities. | Stream Read Only. |
stream_editor | Allows viewing all Groups and Monitoring pages. | Stream Editor. |
stream_admin | Superuser Role at the Product level | Stream Admin. |
Edge Roles
Name | Description | Permission Equivalent |
---|---|---|
edge_user | Basic Role for Edge. | Edge User. |
edge_reader | Allows viewing all Members, Fleets, Settings, Leader commits, and legacy Local Users and Roles, with no configuration capabilities. | Edge Read Only. |
edge_editor | Allows viewing all Groups and Monitoring pages. | Edge Editor. |
edge_admin | Superuser Role at the Product level. | Edge Admin. |
Fleet–Level Roles
Name | Description | Permission Equivalent |
---|---|---|
owner_all | Read/write access to (and Deploy permission on) all Fleets. | N/A |
editor_all | Read/write access to all Fleets. | N/A |
reader_all | Read-only access to all Fleets. | N/A |
collect_all | Ability to create, configure, and run Collection jobs on all Worker Groups. | N/A |
Cribl strongly recommends that you do not edit or delete these default Roles. However, you can readily clone them, and modify the duplicates to meet your needs.
Cribl Search and Cribl Lake RBAC
Because Cribl Search and Cribl Lake are available only in Cribl.Cloud, they use Cribl’s newer Members/Permissions access-control system. For details about managing access to these products and their resources, see:
Initial Installation or Upgrade
When you first install Cribl Edge with the prerequisites to enable RBAC (Distributed deployment with an Enterprise license), you will be granted the admin Role. Using this Role, you can then define and apply additional Roles for other users.
You will similarly be granted the admin Role upon upgrading an existing Cribl Edge installation from pre-2.4 versions to v. 2.4 or higher. This maintains backwards-compatible access to everything your organization has configured under the previous Cribl Edge version’s single Role.
Adding and Modifying Roles
To add a new Role:
- In the sidebar, select Settings, then Global.
- Under Access Management, select Roles.
- Select Add Role.
- Provide the Role Name.
- Select Policies for this Role.
Adding and Removing Policies
The Policies section is an expandable table. In each row, you select a Policy using the left drop-down, and apply that Policy to objects (i.e., assign permissions on those objects) using the right drop-down.
Let’s highlight an example from the above screen capture of Cribl Edges built-in Roles: The editor_all
Role has the GroupEdit
Policy, with permission to exercise it on any and all Fleets (as indicated by the *
wildcard).

To add a new Policy to a Role:
- Select Add Policy to add a new row to the Policies table.
- Select a Policy from the left column drop-down.
- Accept the default object on the right; or select one from the drop-down.
To modify an already-assigned Policy, just edit its row’s drop-downs in the Policies table.
To remove a Policy from the Role, select the X icon at right.
In all cases, click Save to confirm your changes and close the modal.
Default Policies
In the Policies table’s left column, the drop-down offers the following default Policies:
Fleet-Level Policies
Name | Description | Permission Equivalent |
---|---|---|
GroupRead | The most basic Fleet-level permission. Enables users to view a Fleet and its configuration, but not modify or delete the config. | Fleet-level Read Only. |
GroupEdit | Building on GroupRead , grants the ability to also change and commit a Fleet’s configuration. | Fleet-level Editor. |
GroupFull | Building on GroupEdit , grants the ability to also deploy a Fleet. | Fleet-level Admin. |
GroupCollect | Grants the ability to create, configure, and run Collectors on a Worker Group. | N/A |
GroupUser | Access Fleet. | Fleet-level User. |
Project-Level Policies
Name | Description | Permission Equivalent |
---|---|---|
ProjectMaintain | Grants ability to edit or delete the Project and its settings. | Project-level Maintainer. |
ProjectRead | Can configure connections among the Project’s Subscriptions, Packs, and Destinations, but cannot modify or delete these resources. | Project-level Read Only. |
ProjectEdit | Can view Project and Subscription settings and connections, but not modify or delete them. | Project-level Editor. |
Product-Level Policies
Name | Description | Permission Equivalent |
---|---|---|
ProductUser | Makes the Member assignable to Worker Groups and resources, with no initial access to any. | Product-level User. |
LimitedProductUser | Similar to ProductUser , but omits the ability to read or act on all the endpoints within a Fleet. | N/A |
ProductAdmin | Superuser Permission at the Product level. | Product-level Admin. |
General Policies
Name | Description | Permission Equivalent |
---|---|---|
* (wildcard) | Grants all permissions on associated objects. | N/A |
Internal Policies
The following policies are internal building blocks for Product-specific Policies. Do not add them directly to Roles.
Name | Description | Permission Equivalent |
---|---|---|
Product | N/A | N/A |
BaseProductUser | N/A | N/A |
MaintainBase | N/A | N/A |
Use Policies As-Is
By design, the default Policies that ship with Cribl Edge cannot be modified via the UI or API. Do not attempt to modify them by other means. Breaking the built-in model could undermine your intended access-control protections, opening your deployment and data to security vulnerabilities.
Objects and Permissions
In the Policies table’s right column, use the drop-down to select the Cribl Edge objects on which the left column’s Policy will apply. The objects available for selection are specific Fleets, or a wildcard representing all Fleets. For example:
Worker Group <id>
NewGroup2
default
(Fleet)*
(all Fleets)
Extending Default Roles
Here’s a basic example that ties together the above concepts and facilities. It demonstrates how to add a Role whose permissions are restricted to a particular Fleet.
Here, we’ve cloned the editor_all
Role that we unpacked above. We’ve named the clone editor_default
.
We’ve kept the GroupEdit
Policy from editor_all
. But in the right column, we’re restricting its object permissions to the default
Fleet that ships with Cribl Edge.

You can readily adapt this example to create a Role that has permissions on an arbitrarily named Fleet of your own.
Roles and Users
Once you’ve defined a Role, you can associate it with Cribl Edge users. For details, see Local Users.
Note that when you assign multiple Roles to a given user, the Roles’ permissions are additive: This user is granted a superset of all the permissions contained in all the assigned Roles.
By default, Cribl Edge will log out a user upon a change in their assigned Roles. You can defeat this behavior at Settings > Global > General Settings > API Server Settings > Advanced > Logout on roles change.
External Groups and Cribl Edge Roles
You can map user groups from external identity providers (LDAP, Splunk, or OIDC) to Cribl Edge Roles, as follows:
- In the sidebar, select Settings, then Global.
- Under Access Management, select Authentication
- Choose LDAP, Splunk, or OpenID Connect as authentication Type.
- Configure your identity provider’s connection and other basics. (For configuration details, see the appropriate Authentication section.)
- Under Role Mapping, first select a Cribl Edge Default role to apply to external user groups that have no explicit Cribl Edge mapping defined below.
- Next, map external groups as you’ve configured them in your external identity provider (left field below) to Cribl Edge Roles (right drop-down list below).
- To map more user groups, select Add Mapping.
- When your configuration is complete, select Save.