/ / /

Members and Permissions

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

Members and Permissions enable fine-grained access control and authorization. You can assign different access and capabilities (Permissions) to each user (Member) at multiple levels:

Organization.
Product: Stream, Edge, or Search.
Group/Fleet.
Resource: Stream Project, Search Dataset or Dataset Provider, and so on.

Availability

Permission-based access control is available on:

Customer-managed Distributed deployments (Stream, Edge) with an Enterprise license.
All Cribl.Cloud deployments, at the Organization level. (A Cribl.Cloud Enterprise plan also offers granular access control on products, Worker Groups, and lower-level resources.)

On customer-managed single-instance deployments, or distributed deployments with other licenses, all users will have full Admin-level privileges.

Initial Permissions

When you first deploy Cribl Stream with the above prerequisites, you will be granted the Organization-level Admin Permission. Using this Permission, you can then assign additional Permissions to yourself and other Members, as outlined below in Organizations and Assigning Group-/Fleet-Level Permissions.

Cross-Compatibility

Members and Permissions are available as the successors to Cribl’s original role-based access control (RBAC) model of Local Users and Roles/Policies. The earlier model is still supported across most of the Cribl product suite.

However, Cribl.Cloud invitations and Stream Projects have fully transitioned to the new model. For detailed differences between the two access control systems, see Which Access Method Should I Use?.

Known Issue

Existing Local Users display on Settings > Members pages 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.

Organizations

The Members and Permissions model uses the concept of Organization as a container for the deployment of a whole suite of Cribl products (Stream, Edge, and Cloud-only Search and Lake).

In Cribl.Cloud, each account has one Organization. Use Workspaces for multi-tenancy within your Organization. Contact Cribl Support if you have a use case that requires more than one Organization.

To access the Organization-level Members as an Admin:

From Cribl Stream’s top nav, select Settings > Global Settings.
From the left nav, select Members and Teams.
Here, you can click an existing Member’s row to change their access Permissions or other details, or click Add Member to grant a new user access to your Cribl Organization.

For Cribl.Cloud’s counterpart to this on-prem UI for managing Organization-level Permissions, see Inviting Members.

Members and Local Users

Members and Local Users are interchangeable: Members can be reconfigured using legacy Roles instead of Permissions, and anyone you add to Local Users will also show in Members.

Organization- and Product-Level Permissions

Each newly created Member starts out with User Permission at the Organization level, and with the self-explanatory No Access Permission on each product. You can use the toggles to assign the following Permission levels.

For Cribl.Cloud Organization-level Permissions, see Cribl.Cloud docs’ Member Permissions section.

Organization-Level Permissions

Permission	Description
User	The most basic Permission. At the Organization level, gets the Member into the system, without conferring any access to peer Members, products, or lower-level resources. (Admins can freely assign these Members varying Permissions at lower levels.)
Admin	This is a superuser Permission. At the Organization level, allows creating, viewing, updating, and deleting all Members. (Automatically inherits Product-level `Admin` Permissions and resource-level `Maintainer` Permissions, which confer comparably broad capabilities.)

For Stream and Edge, the Product-level Permissions below apply to both Cribl.Cloud and on-prem deployments. For Cribl Search’s more-specific Product-level Permissions, see Search Member Permissions. For Cribl Lake’s Product-level Permissions, see Lake Permissions.

Product-Level Permissions (Stream and Edge)

Permission	Description
User	The most basic Permission. At the Product level, makes the Member assignable to Worker Groups and resources, with no initial access to any.
Read Only	At the Product level, this Permission is designed specifically to enable support personnel to help other users by viewing (but not modifying) their configurations. Allows viewing all Members, Worker Groups, Settings, Leader commits, and legacy Local Users and Roles, with no configuration capabilities. (A `Read Only` Permission at the Product level automatically inherits `Read Only` Permissions on all Worker Groups and lower-level resources.)
Editor	Allows viewing all Groups and Monitoring pages. (Configuring these options requires `Admin`-level permission on the product and/or Worker Group.) Automatically inherits the `Editor` Permission on Worker Groups, and the `Maintainer` Permission on lower-level resources.
Admin	This is a superuser Permission at the Product level. It allows creating, viewing, updating, and deleting all Worker Groups and resources; managing Worker Group Mappings; adding, updating, and restarting Worker Nodes; and managing Notifications and Notification targets. (Automatically inherited from the Organization-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 and `Maintainer` Permissions on lower-level resources.)

Once Members are in your Organization, you can assign or reassign the above Organization- and Product-level Permissions. Return to Settings > Global Settings > Members and click the Member’s row to reopen the same configuration modal.

Group- and Fleet-Level Permissions

Cribl Stream Permissions at the Worker Group level generally mirror those at the Product level:

Permission	Description
User	The most basic Permission. Gets the Member into the Worker Group, where Admins can then assign them access on individual resources. (Unless Members have a higher Permission at the Product level, they have no initial access to Worker Groups or resources.)
Read Only	Designed for support personnel. Allows viewing all Worker Group-level Settings, encryption keys, certificates, secrets, scripts, Sources, Destinations, Pipelines, Packs, Routes, QuickConnect connections, Knowledge objects, Notifications and Notification targets, Edge Subfleets and their Settings, and Stream Projects and Subscriptions, with no configuration capabilities. (Automatically inherited from a Product-level `Read Only` Permission. Automatically inherits `Read Only` Permissions on lower-level resources.)
Editor	Allows creating, viewing, updating, and deleting all Worker Group-level encryption keys, certificates, secrets, scripts, Sources, Destinations, Pipelines, Packs, Routes, QuickConnect connections, Knowledge objects, and Notifications and Notification targets. Allows committing configuration changes, but not deploying them. (An `Editor` Permission at the Product level automatically inherits `Editor` Permissions on all Worker Groups.)
Admin	Superuser Permission. Allows creating, viewing, updating, and deleting all Worker Group-level access management (Members’ Permissions), Settings, encryption keys, key management system (KMS) settings, certificates, secrets, scripts, Sources, Destinations, Pipelines, Packs, Routes, QuickConnect connections, Knowledge objects, Notifications and Notification targets, and Stream Projects/Subscriptions. Allows adding, updating, and restarting Worker Nodes. Allows committing and deploying configuration changes. On Edge, provides CRUD capabilities on Subfleets’ Settings and access management identical to those on the parent Fleet. (Automatically inherited from the Product-level `Admin` Permission. Automatically inherits `Maintainer` Permissions on lower-level resources.)

Assigning Group-/Fleet-Level Permissions

To assign Permissions on a Worker Group:

Select Settings > Global Settings > Members and Teams.
Make sure this Member has an Org Permission level sufficient to support the Permission you want to assign on the Worker Group.
From the top-left product switcher, select Cribl Stream. Then select Settings > Cribl Stream Settings > Members and Teams.

Click each applicable Member’s row to open their User Details drawer.

Grant the Member the Permission level you want on this Worker Group.

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 4.1.x project_user Role and ProjectSourceSubscribe Policy, which provided access to all Projects, are retired in Cribl Stream 4.2.x and later. 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.

Search Resources

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, 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, 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 and on lower-level resources.

Members and Permissions