Skip to content
LogScale Self-Hosted
This is an archived version of the documentation downloaded from LogScale Documentation Archives. Up to date documentation, and documentation for later versions, is available on LogScale Documentation

# Manage Users and Permissions

##### Security Requirements and Controls

- `Change organization permissions` permission

- `Manage users` permission

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.

## Access Control Concepts

The RBAC model is centered around three concepts: users, groups, and roles. An overview of the RBAC model is shown in the diagram below.

%%{init: {"flowchart": {"defaultRenderer": "elk"}} }%% graph LR; subgraph Group u1[User] u2[User] u3[User] end subgraph Role RA[Admin] RU[User] RQ[Query] end subgraph Permissions P1[Permission] P2[Permission] P3[Permission] end subgraph Resource RR[Repository] RO[Organization] RC[Cluster] end Group <--> Role Role --> Permissions RA --> RO RU --> RR
Diagram illustrating the core components and relationships of LogScale's role-based access control (RBAC) model. The flowchart shows four main elements organized in groups: Users contained within Groups, different role types (Admin, User, and Query), individual Permissions, and Resources (Repository, Organization, and Cluster). The diagram demonstrates the key relationships between these elements: Groups connect to Roles (bidirectional relationship), Roles connect to Permissions (one-way relationship), and specific roles map to specific resources (Admin role connects to Organization, User role connects to Repository). This visualization represents how permissions flow from users through groups and roles to enable specific actions on different system resources.

Figure 102. Authorization Concepts

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

- Users

  In LogScale, a user is allowed to do specific actions 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. 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 provide permit different actions in 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, giving all members of the group the permissions contained in the role. A user action on a repository is allowed, or authorized, if the user is a member of a group that has a role containing the needed permission.

At repository level, roles can be assigned to a user directly, without needing a Group.

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, Tom is both a member of Support UK and Devs DK which makes him an Admin and a Searcher in the Web Log repository.

Root access is a per-user property and independent of Roles and Groups. See Root access.

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 always assigned in sets called `Roles`.

If you're 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 by default have the permissions required to assign roles to users.

For more information, see the following documentation pages:

> Permission Levels for information on the different permission levels available.

> 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 and View Permissions for a list of the different permissions that can be assigned.

#### Enter search term