On This Page

Home / Identity and Access Management/Access Control

Access Control

Cribl supports two models for managing user access: the Permissions model and the Roles and Policies model.

  • The Permissions model is Cribl’s modern approach for fine-grained access control from the Organization level down to individual resources.

  • The Roles and Policies model is Cribl’s legacy role-based access control (RBAC) system.

Cribl.Cloud supports only the Permissions model. On-prem deployments support both the Permissions model and the legacy Roles and Policies model.

Model Availability
​

Your deployment type and license tier determine which access control models and levels of granularity are available.

Permissions Model Availability
​

On Cribl.Cloud, the Permissions model is always available at the Organization level. More granular control at lower levels (Workspaces, products, and resources) requires certain plan/license tiers.

In on-prem Distributed deployments (Stream, Edge), the Permissions model is available at certain plan/license tiers.

In on-prem Single-instance deployments and Distributed deployments at other license tiers, Cribl bypasses the Permissions model and assigns all users implicit Admin Permissions.

Roles and Policies Model Availability
​

Cribl.Cloud does not support the Roles and Policies model.

In on-prem Distributed deployments (Stream, Edge), the Roles and Policies model is available only at the Enterprise license tier.

In on-prem Single-instance deployments and Distributed deployments at other license tiers, all users have full administrative access. Cribl does not enforce role-based access control (RBAC).

When to Use Each Access Control Model
​

On Cribl.Cloud, you must use the Permissions model.

On-prem deployments support both the Permisisons and Roles and Policies models, which are mostly cross-compatible. If you’re already using Roles and Policies, you can continue to do so, although we recommend migrating to Permissions for new users, features, and on-prem deployments. However, certain cases require you to use a specific model.

The following cases require the Permissions model:

The following cases require the Roles and Policies model:

  • Authorizing a GitOps integration requires the legacy gitops Role. This legacy Role has no counterpart Permission.

  • Managing access to create, configure, and run Collection jobs on all Worker Groups and Edge Fleets requires the collect_all Role. This Role does not have a counterpart Permission. You can grant the Collect Permission only on individual Worker Groups and Edge Fleets in the Permissions model.

  • Managing access to create and receive all Notifications requires the notification_admin Role. This Role does not have a counterpart Permission. In the Permissions model, you can grant access to Notifications only on Cribl Stream and Edge and individual Worker Groups and Edge Fleets.