Role Based Access Control#

Role-Based Access Control (RBAC) allows you to restrict access to Observe based on the assigned group(s) in your organization. You can add users to groups with specific permissions within your Observe instance. For example, you may have users that you assign view-only privileges, and allow them to view only certain Datasets within your Observe instance. For other users, you may assign a user to a group that provides access to Datasets and then perform activities within the Dataset, such as creating Dashboards or modeling the data using OPAL.

Built-In Group Permissions#

Observe provides 4 default groups out of the box. Each built-in group has permissions that allow the user to perform specific actions in Observe.

Lister Reader Writer Administrator
  • List metadata about datasets, worksheets, dashboards, monitors, etc.
  • Create, modify, and visualize individual Worksheets
  • Query shared Worksheets, Dashboards, and Datasets
  • View Monitors
  • All Reader actions
  • Create and modify any or all Worksheets, Dashboards, Datasets, Monitors, Datastreams, and Ingest Tokens.
  • Manage Acceleration Jobs using Acceleration Manager
  • All Writer actions
  • Enable and disable users
  • Modify user roles and expiration periods

RBAC Policies & Permissions#

When you set permissions using RBAC, Observe recommends that you grant only the permissions required to perform a task. You do this by defining the actions taken on specific resources (objects) under specific conditions, also known as least-privilege permissions. You might start broad, while you explore the specific permissions required for your workload or use case. As your use case matures, you can work to reduce the permissions that you grant to work toward least privilege.

Policy Evaluation Flow#

Observe evaluates the RBAC rules for a request in a defined order. This means that RBAC statements will take precedence over others, based on the order in which they are matched.

RBAC Evaluation Infographic

Figure 1 - RBAC Policy Evaluation

First, if a user is a member of the Administrator group (permission Admin for all objects), either directly or via an intermediate group, the request will be allowed.

Next, the system will look for RBAC statements that match the requested object, from most to least specific. The request will be evaluated against the first matching statement using the statement’s role. All subsequent matching statements (broader scopes) will be ignored.

Lastly, requests will match the built-in defaults if no user-defined statement is matched. Currently, this provides Lister access to all objects.

Policy Evaluation Example#

For example, if a user is attempting to access a dataset O11y Logs, and this user has two statements that both target the same dataset with Viewer and Manager permissions, the Manager permission will take precedence. This is because the Manager permission is more permissive. Once again the evaluation flow is:

  • Determine all rules that might apply to this access request. (user is a member of two groups)

  • Determine the most specific scope within these rules. (dataset O11y Logs is specifically targeted)

  • Determine the most permissive permission granted within that scope. (Manager is more permissive than Viewer)