Manage users & permissions

Security Requirements and Controls

LogScale's role-based access control (RBAC) model enables authorization of users based on roles with different sets of permissions. LogScale distinguishes between authentication, which establishes the identity of the user, and authorization, which decides what are the actions an authenticated user may perform.

There are four primary areas for which permissions are applicable: the whole LogScale System (cluster), the Organization, the Repository, and the Asset. LogScale distinguishes between Repository (and View) Permissions, and Organization and Cluster Permissions. Different sets of permissions apply to each resource, but permissions are not inherited.

Organization and Cluster Permissions

Organization and cluster permissions are separate from Repository and View permissions. Cluster permissions are only applicable for self-hosted environments.

block-beta columns 1 System block:Organizations A["Organization A"] style A fill:#799,stroke:#333; B["Organization B"] style B fill:#969,stroke:#333; C["Organization C"] style C fill:#999,stroke:#333; end block:Repositories 1["Repository 1"] style 1 fill:#8999,stroke:#333; 2["Repository 2"] style 2 fill:#6999,stroke:#333; 3["Repository 3"] style 3 fill:#4999,stroke:#333; 4["Repository 4"] style 4 fill:#989,stroke:#333; 5["Repository 5"] style 5 fill:#977,stroke:#333; 6["Repository 6"] style 6 fill:#967,stroke:#333; 7["Repository 7"] style 7 fill:#9994,stroke:#333; 8["Repository 8"] style 8 fill:#9996,stroke:#333; 9["Repository 9"] style 9 fill:#9999,stroke:#333; end block:Asssets z["Asset 1"] style z fill:#8999,stroke:#333; y["Asset 2"] style y fill:#8999,stroke:#333; x["Asset 3"] style x fill:#6999,stroke:#333; w["Asset 4"] style w fill:#6999,stroke:#333; v["Asset 5"] style v fill:#4999,stroke:#333; u["Asset 6"] style u fill:#4999,stroke:#333; t["Asset 7"] style t fill:#989,stroke:#333; s["Asset 8"] style s fill:#989,stroke:#333; r["Asset 9"] style r fill:#977,stroke:#333; q["Asset 10"] style q fill:#977,stroke:#333; p["Asset 11"] style p fill:#967,stroke:#333; o["Asset 12"] style o fill:#967,stroke:#333; n["Asset 13"] style n fill:#9994,stroke:#333; m["Asset 14"] style m fill:#9994,stroke:#333; l["Asset 15"] style l fill:#9996,stroke:#333; k["Asset 16"] style k fill:#9996,stroke:#333; j["Asset 17"] style j fill:#9999,stroke:#333; i["Asset 18"] style i fill:#9999,stroke:#333; end

Note

You need to be either the nominated Organization Owner for your organization to access and create repository and organization role types, or alternatively, you must have the CreateRepositories organization permission assigned to you through an organization group level to create repositories, and the ManageUsers organization permission assigned to you directly to manage roles, groups, and users in the organization.

Repository and View Permissions

Repository and view permissions grant repository level permissions for accessing a selection of repositories and views, or assets that are included in a view.

Repository and view permissions are mainly assigned by groups and roles, but they can be assigned at a more fine-grained level if required, even at the individual asset level and what specific actions may be performed on the asset.

The RBAC model is centered around three concepts: users, groups, and roles. In LogScale, users are allowed to do specific actions if one or more needed permissions are assigned to them. Permissions can be assigned either directly to the user or via a group of which they are a member. Permissions are generally assigned in sets called Roles, but asset permissions can be assigned directly to users and groups. An overview of the RBAC model is shown in the diagram below.

flowchart LR A(User A) --> B((Group 1)) Z(User Z) --> B((Group 1)) Z --> G B -- Query Prefix Gp1 View X --> C{View X} C --> D(Role D) subgraph PermissionsRoleD direction LR asset1[Edit Files] asset2[Edit Dashboard] end D --> PermissionsRoleD F(User B) --> G((Group 2)) Y(User Y) --> G((Group 2)) G -- Query Prefix Gp2 View Y --> H{View Y} H --> J(Role M) subgraph PermissionsRoleM direction LR asset3[View Data and Assets] end J --> PermissionsRoleM X(User X) --> Q((Group 3)) Q -- Query Prefix Gp3 View Y--> H{View Y} Q -- Query Prefix Gp3 View W --> W{View W} W --> E(Role E) W --> J subgraph PermissionsRoleE direction LR asset5[Edit Actions] asset6[Edit Triggers] end E --> PermissionsRoleE

Figure 49. Repository and View Permissions


In the diagram, users are assigned to groups. Groups are assigned one or more views. And Views are assigned one or more roles that have permissions. A user can belong to multiple groups, such as User Z and User Y. A Group can have multiple views, such as Group 3 which has both View Y and View W. And Views can have one or more roles, such as View W that has both Role E and Role M.

If a user is member of more than one Group that has been assigned a role in a specific repository, the user has the combined permissions from the roles involved. So in the above diagram, User Z is a member of two groups and gets the permissions for both groups. This is in contrast to User A who is only a member of Group 1 and gets only the permissions for that group.

Group 3 has the permissions in Role M assigned twice. The thing to notice here is that role and permissions assignment must be evaluated in the context of a specific View. So the assignment of Role M for View Y allows the user to see the data and assets in View Y, and the assignment of Role M for View Z allows the user to see the data and assets in View Z.

  • Users

    In LogScale, a user is allowed to do specific activities if one or more needed permissions are assigned them. Permissions can be assigned either specifically to the user, or via a Group of which they are a member.

  • Groups

    Groups contain Users, which provide access for the users that are members of the group. Groups collect multiple users together into manageable collections with specific permissions provided by Roles, and/or directly assigned Asset Permissions.

  • Roles

    Roles define the permissions given to a user or a group of users across a range of access rights.

  • Permissions

    Permissions are specific to a given resource and there are different sets of permissions that permit different actions for each resource. For example, it is possible to create a Role with the permission to read data stored in a repository, but not have the ability to change triggers or actions within that repository.

    Permissions are also not shared, inherited, or transferable to a different resource. A role that provides permissions for managing an organization does not provide the ability to access data. However, that role may have permissions to create a user that could access the data in a repository.

  • Assets

    Assets describe some of the objects in LogScale that enable you to get data into or out of LogScale, or to view data. Examples of assets are: triggers, actions, dashboards, files, saved queries, and scheduled reports.

    Asset permissions can be granted through a role, or they can be granted to individual users or groups.

Groups are assigned roles in the context of a repository or view, giving all members of the group the permissions contained in the role. A group can have multiple views through which they have permissions from multiple roles. A user action on a repository or view is allowed, or authorized, if the user is a member of a group that has a role containing the needed permission in the context of this repository or view.

At the repository level, roles can be assigned to a user directly, without needing a Group. For information about how to do this, see Manage User Roles.

If you are the one setting up LogScale — either because you have created a new organization on LogScale Cloud and you are the owner, or you are a root user of an self-hosted installation — you will have the permissions required to assign roles to users by default.

The base security architecture is closely related to the API Token architecture. For more information, see Figure 22, “API Token Architecture in LogScale”.

Asset permissions

You can grant a user permissions to a view or to an individual asset if you want to collaborate on a specific project without needing an administrator to assign permissions.

In order to grant permission to an asset to another user, you must have permissions that allow you to grant the user permission to that asset. For example, if a user giving permissions is trying to give permissions to a user who does not have read access on the repo, the user granting permissions will need Manage users permission or Change user access on the repo or Change organization permissions on the organization. If the user granting permissions does not have any of these permissions but has permissions another way (for example, the user created the asset), they can only grant up to the same level of permissions that they have. If the user receiving permissions already has read permissions, then the user giving permissions can only give as much access as they have: if they have edit, they can give edit but not delete.

This functionality is limited to the following asset types:

  • Dashboards

  • Actions

  • Files

  • Saved Queries

  • Scheduled Reports

  • Triggers

Share assets in a view

When you share the view, you share all of the assets in the view as shown in the diagram. User B wants to collaborate with User Y. Because User B has the permissions to be able to share this with User Y, User B can grant view permissions to User Y.

flowchart LR F(User B) --> G((Group 2)) F -. I think you should also see this .-> Y Y(User Y) -. Can see all assets in view .-> H G -- Query Prefix --> H{View Y} H --> J(Role M) subgraph Permissions direction LR asset3[View Data and Assets] end J --> Permissions

The permissions for "View Data and Assets" are given through the Data Read Access permission.

If a user or group doesn't have any view permission to a view, you cannot assign direct permissions to that user or group in the view.

Share edit and delete assets

A user can also grant higher level permissions to individual assets. By higher level, this means that the user may be able to grant another user permissions to edit or even delete certain assets. It requires that the granting user has authority to give those permissions. In the diagram below, User A wants to work with User Z on a particular dashboard. Because User A has permission, User A can grant User Z edit permission for the dashboard they will work on. User Z does not get any other permissions that User A has (such as editing files); nor can User A edit other dashboards, only this dashboard, unless User Z has permissions some other way that grant them permissions to edit other dashboards.

flowchart LR A(User A) --> B((Group 1)) A -. Want to collaborate? .-> Z(User Z) B -- Query Prefix --> C{View X} C --> D(Role D) subgraph PermissionsRoleD direction LR asset1[Edit File] end D --> PermissionsRoleD subgraph PermissionsForDashboard1 direction LR asset2[Edit Dashboard] end A --> PermissionsForDashboard1 Z -. Edit only this asset .-> asset2
Asset permissions on roles

The asset permissions assigned on roles give users with that role the ability to perform the selected activities within the view assigned to the role. This provides a simple way to assign granular permissions to multiple users. For example, you could allow users with a particular role to create and edit dashboards, but not delete them.

For information about how to grant edit and delete permissions for actions, see Manage Actions.

For information about how to grant edit and delete permissions for dashboards, see Manage Dashboards.

For information about how to grant edit and delete permissions for files, see Lookup Files.

For information about how to grant edit and delete permissions for saved queries, see Saving Queries.

For information about how to grant edit and delete permissions for scheduled reports, see Managing Scheduled Reports.

For information about how to grant edit and delete permissions for triggers, see Manage triggers.

Permission Levels

LogScale enables you to choose between different permission levels, or types, each collecting a set of permissions that are valid for a given role. These levels grant a set of permissions to roles and then assign these roles to groups.

While creating a new role, you are prompted to choose one of these levels of permissions permission, thus defining that role as belonging to a given permission level.

When creating a new group, you are also asked to choose a permission level: this way, the group is associated with a specific permission type, which comes with a given set of permissions.

For more information, see the following documentation pages:

Manage Users for information on how to create users.

Manage Groups for information on how to assign users and permissions to groups, set group memberships and synchronize groups.

Manage Roles for information on how to manage roles and assign permissions.

Repository & View Permissions for a list of the different permissions that can be assigned.