Cribl’s Permissions model provides fine-grained access control from the entire deployment down to individual resources.

Permissions are defined sets of access rights on Cribl Organizations, Workspaces, products, Worker Groups and Edge Fleets, and resources. You assign Permissions to Members, the individual users who can access your Cribl deployment. You can assign Permissions to Teams to efficiently assign Permissions to groups of Members.

Members also inherit Permissions on lower-level objects like products and Worker Groups from the Permissions they are assigned on higher-level objects like Organizations and Workspaces.

Cribl.Cloud supports only the Permissions model. On-prem deployments support both the Permissions model and the legacy Roles and Policies model. Read more about when to use each access control model.

Inheritance ​

Inheritance means that the Permission you assign to a Member on a higher-level object (such as an Organization) determines which Permissions the Member has on lower-level objects (such as Workspaces and products).

In most cases, Permissions on higher-level objects like Organizations “lock” the Permissions on lower-level objects. For example, in Cribl.Cloud, Members with the Admin Permission on an Organization automatically inherit the Admin Permission on Workspaces, Cribl products, and Worker Groups and Edge Fleets in the Organization, as well as the Maintainer Permission on resources.

The object-specific sections in the Permissions topic include diagrams that explicitly define the inheritance for each Permission on each object, such as Inheritance for Organization Permissions.

The following diagrams depict the object-level hierarchy for Permission inheritance in Cribl.Cloud and on-prem deployments:

Organization
└── Workspace
    └── Product (Cribl Stream and Edge)
        └── Worker Group or Edge Fleet
            └── Resource
    └── Product (Cribl Search and Lake)
        └── Resource

Global
└── Product (Cribl Stream and Edge)
    └── Worker Group or Edge Fleet
        └── Resource

Permission Conflicts ​

If a Member has conflicting Permissions from direct assignment, assignment by Team membership, or inheritance, the most permissive Permission takes precedence.

For example, suppose that a Member is assigned the following Permissions on Cribl Search:

• User Permission via membership in Team A.
• Editor Permission via membership in Team B.
• User Permission via direct Member assignment.

In this example, the Member has the Editor Permission on Cribl Search, the highest effective Permission of those assigned and the most permissive access.