On This Page

Home / Identity and Access Management/Permissions

Permissions

Define and manage fine-grained access control across Cribl products and resources.


You can assign different access and capabilities (Permissions) to each user (Member) or user group (Teams) at multiple levels:

Organization-Level Permissions (Cribl.Cloud)

Assign Organization-level Permissions per individual user when you invite them to your Organization as Members or by updating an Organization Permissions assigned to a user after they join.

If you configured SSO, grant Organization-level Permissions by managing group membership within your IdP. Make sure that your IdP group names align with the core patterns for automatic Permission mapping.

Cribl.Cloud does not support globally predefining Permissions, as with on-prem deployments.

PermissionUserIAM AdminAdminOwner
Log into the system
Update own Member profile
View Stream Worker Groups to which you have access
Admin Access to all Products
View and execute Leader commits
View and modify Global Settings
Manage ACLs (Access Control lists)
View and update SSO settings
View Data Sources and Trust Policies
Manage API Credentials
View and manage Cribl Suite Global Settings
View and manage (provision, update, and delete) Stream Worker Groups
View the credit consumption dashboards in the FinOps Center
Download invoices
View Organization Details
Update Organization Details
Delete an Organization
View Organization Members
Manage (invite, update, delete) Organization Members
Create and delete Lakehouses
Link and unlink Lakehouses with Datasets

Each user can have Owner Permissions for multiple organizations, and each organization can have multiple users as Owners. However, each user - as defined by their email address - can register only one active Organization, and only if they are not already the Owner of a different Organization.

Cribl.Cloud does not use the earlier access-management model of Local Users and Roles/Policies that on-prem deployments still support. You can create and configure only Members and Permissions - and optionally, Teams - on Cribl.Cloud Organizations and applications (Cribl Search and Cribl Lake). References elsewhere in Cribl docs to Local Users, Roles, and Policies do not apply to Cribl.Cloud Organizations or applications.

Workspace-Level Permissions

Workspace-level Permissions differ between Cribl.Cloud and on-prem deployments. Because multiple Workspaces are available only on Cribl.Cloud, Workspace-level Permissions in on-prem deployments cover the whole Organization (that is, the whole deployment). In Cribl.Cloud, you can set specific Permissions separately for each Workspace.

Workspace-Level Permissions (Cribl.Cloud)

PermissionMemberAdminOwner
Log into the system
View ACLs, Workspace details and users
View default data sources and trust policy
Manage ACLs

Workspace Owners (ws_owner) and Admins (ws_admin), cannot invite, update, or delete Members. They can view the existing Members of their Workspace directly within the product-specific UI (such as, Cribl Stream or Cribl Edge). To view the Members in a specific Cribl.Cloud Workspace, navigate to Workspace > Product (Stream or Edge) > Settings > Access > Members and Teams.

Workspace-Level Permissions (on-prem)

PermissionUserAdmin
Log into the system
Create, view, update, and delete all Members.

An Admin Permission inherits Product-level Admin Permissions and resource-level Maintainer Permissions.

Product-Level Permissions

Product-level Permissions let you grant Members access to particular actions and resources for Cribl Stream, Edge, Search, and Lake.

Stream and Edge Permissions

You can assign the following Permissions at the Cribl Stream or Cribl Edge product level.

PermissionUserRead OnlyEditorAdmin
Can be assigned to Worker Groups/Fleets and resources
View all Members, Worker Groups/Fleets, Settings, Leader commits, and legacy Local Users and Roles
View all Groups and Monitoring pages
Create, view, update, and delete all Worker Groups/Fleets and resources
Manage Worker Group/Fleet Mappings
Add, update, restart Worker Groups/Fleets
Manage Notifications and Notification Targets

Product-level Permissions inherit Permissions of a different level in the following manners:

  • A Read Only Permission automatically inherits Read Only Permissions on all Worker Groups/Fleets and lower-level resources.
  • An Editor Permission inherits the Editor Permission on Worker Groups/Fleets, and the Maintainer Permission on lower-level resources.
  • An Admin Permission inherits from the Workspace-level Admin Permission in on-prem deployments, and from the Org-level Owner Permission in Cribl.Cloud deployments. Automatically inherits Admin Permissions on all Worker Groups/Fleets and Maintainer Permissions on lower-level resources.

Search Permissions

You can assign the following Permissions at the Cribl Search product level.

PermissionUserEditorAdmin
Data, Dashboards, and Libraries
Create, configure, view, and modify Datasets
Create, configure, view, and modify Dataset Providers
Unhide Dataset Provider credentials
Create, configure, view, and modify Dashboards
Create, configure, view, and modify saved and scheduled searches
Create, configure, view, and modify settings like Datatypes
and Event Breakers
Create, configure, view, modify, and export to lookups
Create, configure, view, and modify other libraries
(Parsers, Regexes, Grok Patterns)
Create, view, use, import, modify, and export Packs
Access Control and Visibility
Invite other users (Members) to the Workspace
Manage other Members
Promote Members to Admins
See search historyOwn searchesOwn searches
Search Query Language
export operator
send operator (see: send Permissions)Default GroupNamed GroupsCustom URL
.cancel commandOwn searchesOwn searches
.show queries commandOwn searchesOwn searches
$vt_datasets virtual table
$vt_dataset_providers virtual table
$vt_jobs virtual tableOwn searchesOwn searches
$vt_lookups virtual table
$vt_results virtual tableOwn searchesOwn searches
set statementsOwn searchesOwn searches
.clear options commandOwn optionsOwn options

Lake Permissions

You can manage access to Lake Datasets by assigning specific product-level Permissions within each Workspace to Members and Teams.

You can assign the following Permissions at the Cribl Lake product level.

PermissionRead OnlyEditorAdmin
Read Lake Datasets
Create and edit Lake Datasets
Delete Lake Datasets
Read Lakehouses
Create and delete Lakehouses
Assign and unassign Lake Datasets to Lakehouses

Some Cribl Lake capabilities require certain product-level Permissions set in other products from the Cribl Product Suite:

CapabilityPermission
View the Integrated with column in the Dataset table, listing the Cribl Lake Collectors and Destinations that a Lake Dataset is connected with.Read Only, Editor, or Admin Permission for Cribl Stream.
Search a Lake Dataset directly from the Dataset table, the Member/Team needs Cribl Search access.User, Editor, or Admin Permission for Cribl Search, and Read Only or higher Permission for this Lake Dataset.

Group- and Fleet-Level Permissions

Permissions at the Stream Worker Group/Edge Fleet level generally mirror those at the Product level:

PermissionUserRead OnlyCollectEditorAdmin
Can be assigned to resources within the Worker Group/Fleet
View all Worker Group/Fleet-level Settings, encryption keys, certificates, secrets, scripts.
View all Sources, Destinations, Pipelines, Packs, Routes, QuickConnect connections, Knowledge objects, Notifications and Notification targets
View all Edge Subfleets and their Settings, and Stream Projects and Subscriptions
Run Collection jobs on the Worker Group/Fleet
Create, view, update, and delete all Worker Group/Fleet-level encryption keys, certificates, secrets, scripts, Sources, Destinations, Pipelines, Packs, Routes, QuickConnect connections, Knowledge objects, and Notifications and Notification targets
Commit configuration changes
Create, view, update, and delete all Worker Group/Fleet-level access management (Members’ Permissions), Settings, encryption keys, key management system (KMS) settings, certificates, secrets, scripts
Create, view, update, and delete all Sources, Destinations, Pipelines, Packs, Routes, QuickConnect connections, Knowledge objects, Notifications and Notification targets, Stream Projects/Subscriptions, and can run tests on Sources and Destinations
Add, update, and restart @{node}s
Commit and deploy configuration changes
On Edge, provides CRUD capabilities on Subfleets’ Settings and access management identical to those on the parent Fleet

Worker Group/Fleet-level Permissions inherit Permissions of a different level in the following manners:

  • A Read Only Permission inherits Read Only Permissions on lower-level resources.
  • An Admin Permission inherits Maintainer Permissions on lower-level resources.

Assign Group-/Fleet-Level Permissions

To assign Permissions on a Stream Worker Group/Edge Fleet:

  1. Make sure this Member has a Workspace permission level sufficient to support the Permission you want to assign on the Worker Group or Fleet.
  2. In the sidebar, select Settings, then Stream/Edge, then Members and Teams.
  3. Select each applicable Member row to open their Member Details drawer.
  4. Grant the Member the Permission level you want on this Worker Group/Fleet.

Assigning Group-/Fleet-Level Permissions in only available in on-prem deployments, not in Cribl.Cloud.

Resource-Level Permissions

Certain Cribl products provide Permission-based access to particular resources.

Stream Projects

Stream Projects and Subscriptions rely entirely on the Members/Permissions access control system. These enable you to assign different users different levels of access on individual Projects.

The v.4.1.x project_user Role and ProjectSourceSubscribe Policy, which provided access to all Projects, are retired in 4.2.x and newer. This is a breaking change. If you are upgrading with Projects configured in v.4.1.x, those Projects’ users will be visible in Stream as Members, and you’ll need to assign them new Permissions.

For details, see Adding Users to Projects.

For Permissions on Search resources, see the Search docs’ Sharing topic.

Other Resources

Access to certain resources can be managed only via legacy Local Users and Roles.

GitOps integration: Authorization to enable and manage GitOps requires the legacy gitops Role. This legacy Role has no counterpart Permission.

Collectors: The collect_all legacy Role specifically enables creating, configuring, and running Collection jobs on all Stream Worker Groups. This Role has no counterpart Permission.

Notifications: The notification_admin legacy Role specifically enables creating and receiving all Notifications. This legacy Role has no counterpart Permission.

Inheritance

Members’ Permissions at certain levels determine the Permissions that Admins can assign them at lower levels. Here is the current inheritance scheme:

  • Members with the Admin Permission at the Organization level will be locked to the Admin Permission on Products, to the Editor Permission on Worker Groups/Fleets, and to the Maintainer Permission on lower-level resources.
  • Members with the Product-level Editor Permission will be locked to the Editor Permission on Worker Groups/Fleets, and to the Maintainer Permission on lower-level resources.
  • Members with the User Permission at each level can be assigned varying Permissions at the next level down. User is the most malleable Permission.
  • On Stream Projects, the Maintainer Permission is available only to Members with higher-level Admin or Editor Permissions. (They’re automatically assigned this Permission via inheritance.)
  • Search resources are more flexible: Here, the Maintainer Permission can be shared with Members who have the User Permission at the Product level.
  • Members with the Product-level Read Only Permission will be locked to the Read Only Permission on Worker Groups/Fleets and on lower-level resources.