Organization-Level Permissions (Cribl.Cloud)

​

You assign Permissions per individual user when you invite them to your Organization, or after they join it. Cribl.Cloud does not currently support globally predefining Permissions, as with on-prem Cribl Edge.

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 has retired the access-management model of Local Users and Roles/Policies that Cribl applications used prior to v.4.2. Create and configure only Members on Cribl applications – references elsewhere in Cribl docs to Local Users do not apply to Cribl.Cloud.

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)

​

Workspace-Level Permissions (on-prem)

​

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

Product-Level Permissions (Stream and Edge)

​

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 inherit Permissions of a different level in the following manners:

• A Read Only Permission automatically inherits Read Only Permissions on all Fleets and lower-level resources.
• An Editor Permission inherits the Editor Permission on Fleets, and the Maintainer Permission on lower-level resources.
• An Admin Permission inherits 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 Fleets and Maintainer Permissions on lower-level resources.

Group- and Fleet-Level Permissions

​

Cribl Edge Permissions at the Fleet level generally mirror those at the Product level:

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 Fleet:

1. Make sure this Member has a Workspace permission level sufficient to support the Permission you want to assign on the Fleet.
2. In the sidebar, select Settings, then Stream/Edge, then Members and Teams.
3. Select each applicable Member’s row to open their Member Details drawer.
4. Grant the Member the Permission level you want on this 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 4.1.x project_user Role and ProjectSourceSubscribe Policy, which provided access to all Projects, are retired in Cribl Edge 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 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 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 Fleets and on lower-level resources.