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 Groups¶
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 |
---|---|---|---|
|
|
|
|
Observe Permissions¶
Observe provides 4 permission types. Permissions apply generally to groups of object types (all dashboards, all worksheets, all datastreams, all monitors, etc.), or specifically to individual objects such as Kubernetes Logs
or AWS Home Dashboard
(for an example of an object specific RBAC policy, see this docs page). You grant permissions to groups and users.
Lister (No Access) | Viewer | Editor | Manager |
---|---|---|---|
|
|
|
|
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.
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)