These docs are for Cribl Stream 4.2 and are no longer actively maintained.

See the latest version (4.13).

Members and Permissions

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

In Cribl Stream 4.2 and later, 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.

Permission-based access control is available only on distributed deployments (Stream, Edge) with an Enterprise license or Cribl.Cloud plan. With other license/plan types and/or single-instance deployments, all users will have full administrative privileges.

In the current release, existing Local Users display incorrectly on Settings > Members pages with No Access Permissions. This is a display-only bug: These users’ original Roles still function as configured. For details and fix timeline, please see Known Issues.

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.

Why Move My Cheese?

​

Members and Permissions enable the finer-grained access control and authorization that many of our users have requested. You can now assign different Cribl users access and capabilities independently at multiple levels:

• Organization.
• Product: Stream, Edge, or Search.
• Group/Fleet.
• Resource: Cribl Stream Project, Cribl Search Dataset or Dataset Provider, etc.

The benefits?:

• Greater security in protecting access to resources and configuration.
• Greater flexibility in authorizing users on different parts of your Cribl suite (i.e., Organization).
• Ability to segment access and authorization to relevant teams.
• Ability to support a greater diversity of users, given these options.

Cribl plans to eventually retire its earlier RBAC model. But for now, both models are supported, to enable users to experiment and switch over at their own pace. As outlined below, several components of the new versus old model are currently interchangeable.

Organizations

​

Cribl.Cloud has, from the start, provided the concept of an Organization as a container for the deployment of a whole suite of Cribl products (Stream, Edge, and Cloud-only Search). The Members and Permissions model brings this concept to customer-managed (on-prem) deployments. Here, to access the Organization-level Members UI as an Admin:

1. From Cribl Stream’s top nav, select Settings > Global Settings.

2. From the left nav, select Members.

3. 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 updated counterpart to this on-prem UI for managing Organization-level Permissions, see Inviting and Managing Other Users.

Members and Local Users

​

The top half of the Members configuration modal is almost identical to Cribl’s original Local Users modal. In the current release, Members and Local Users are interchangeable: Members whom you add here can be reconfigured in the traditional Local Users UI (using legacy Roles instead of Permissions), and anyone you add in Local Users will also show up here in Members.

So let’s focus on the modal’s bottom half, which is more interesting – the new graphical Permissions management.

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 click along the sliders to assign the following Permission levels.

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

Organization-Level Permissions

​

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.

Product-Level Permissions (Stream and Edge)

​

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:

Assigning Group-/Fleet-Level Permissions

​

To assign Permissions on a Worker Group:

1. Select Settings > Global Settings > Members.
2. Make sure this Member has an Org Permission level sufficient to support the Permission you want to assign on the Worker Group.
3. From the top-left product switcher, select Cribl Stream. Then select (depending on the product) Settings > Stream Settings > Members or Settings > Edge Settings > Members.

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

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

To change Members’ existing Permissions, repeat the same steps above.

Resource-Level Permissions

​

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

Stream Projects

​

In Cribl Stream 4.2 and later, Stream Projects and Subscriptions rely entirely on the Members/Permissions access control first introduced in Stream 4.2. 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 now retired.

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.

Inheritance

​

In the current release, 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.

UX Customization

​

Cribl Stream’s UI will be presented differently to users who are assigned Permissions that impose access restrictions. Some controls will be visible but disabled, and some internal-search and log results will be limited, depending on each user’s Permissions.

Access to the same objects via Cribl Stream’s API and CLI will be similarly filtered, with appropriate error reporting. E.g., if a user tries to commit and deploy changes on a Worker Group/Fleet where they are not authorized, they might receive a CLI error message like this: git commit-deploy command failed with err: Forbidden

Legacy Roles and Policies

​

To facilitate a smooth transition to Cribl’s new access-control model – and to provide backward compatibility for customers still using our earlier Roles/Policies model – our pre-4.2 Roles have been supplemented with new counterparts to most of the new Permissions listed above.