Help Center/ Cloud Search Service/ User Guide/ Using Elasticsearch for Data Search/ Managing Elasticsearch Clusters/ Creating Users for an Elasticsearch Cluster and Granting Cluster Access
Updated on 2024-10-26 GMT+08:00
View PDF
Share

Creating Users for an Elasticsearch Cluster and Granting Cluster Access

CSS limits access to security-mode clusters to authorized users only. When creating a security-mode cluster, an administrator account must be created. This administrator account can later use Kibana to add new users for the cluster and grant them the required permissions. This topic uses Kibana 7.6.2 as an example to describe how to use Kibana to grant users access to a security-mode cluster.

Context

CSS uses the opendistro_security plug-in to provide security cluster capabilities. The opendistro_security plug-in is based on the RBAC model. RBAC involves three core concepts: user, action, and role. RBAC simplifies the relationship between users and actions, simplifies permission management, and facilitates permission expansion and maintenance. Figure 1 shows the relationship between the three.

Figure 1 User, action, and role
Table 1 Concept

Parameter

Description

User

A user can send operation requests to an Elasticsearch cluster. The user has credentials such as username and password, and zero or multiple backend roles and custom attributes.

Role

A role is a combination of permissions or action groups, including operation permissions on clusters, indexes, documents, or fields.

Permission

A single permission, for example, creating an index (for example, indices:admin/create).

Role mapping

A user will be assigned a role after successful authentication. Role mapping is to map a role to a user (or a backend role). For example, the mapping from kibana_user (role) to jdoe (user) means that John Doe obtains all permissions of kibana_user after being authenticated by kibana_user. Similarly, the mapping from all_access (role) to admin (backend role) means that any user with the backend role admin (from the LDAP/Active Directory server) has all the permissions of role all_access after being authenticated. You can map a role to multiple users or backend roles.

Action group

An action group is a group of permissions. For example, the predefined SEARCH action group grants roles to use _search and _msearchAPI.

In addition to the RBAC model, Elasticsearch also uses a concept called tenant. The RBAC model addresses the problem of user-level authorization, while the tenant model addresses the problem of data and resource sharing between different tenants. Within a tenant space, tenants can share information such as dashboards and index patterns.

By default, users can only see the index patterns and dashboards in their own private tenant space. When a new user test is added, the system automatically generates an index named .kibana_xxx_test. The data in this user's private space will be stored in this index. Similarly, the data of the administrator's private tenant space is stored in the .kibana_xxx_admin index. To share an index pattern or dashboard with other tenants, you can create them in the global tenant space. Other users can access the shared resource only by switching to the global tenant space.

On the Kibana console, you can configure user permissions on an Elasticsearch cluster under Security to implement fine-grained access control at four levels: cluster, index, document, and field.

Users can be added or deleted for a cluster, and mapped to specified roles. This way, you assign roles to users.

With role mapping, you can configure the members of each role and assign roles to users based on usernames, backend roles, and host names. For each role, you can configure cluster, index, and document permissions, as well as the permission to use Kibana.

For more about security configuration for a security-mode cluster and the detailed guide, see the official Elasticsearch document here.

Constraints

  • You can customize the username, role name, and tenant name in Kibana. Chinese characters are not allowed.
  • The Kibana GUI varies depending on the Kibana version. Kibana 7.6.2 is used as an example here.

Creating a User and Granting Permissions

  1. Log in to the CSS management console.
  2. Choose Clusters in the navigation pane. On the Clusters page, locate the target cluster and click Access Kibana in the Operation column.
  3. Log in to Kibana using an administrator account.
    • Username: admin (default administrator account name)
    • Password: Enter the administrator password you set when creating the cluster in security mode.
  4. After a successful login, choose Security in the navigation tree on the left of the Kibana operation page. The Security page is displayed.
  5. Add a new user test for the security-mode cluster.
    1. Choose Authentication Backends > Internal Users Database.
    2. On the Internal Users Database page, click +. The page for adding a new user is displayed.
      Figure 2 Adding a user
    3. On the user creation page, specify Username, Password, and Repeatpassword, and click Submit.

      The username test is used as an example here. If created successfully, the new user is displayed in the user list.

  6. Create a role named role_test and assign permissions to it.
    1. Click Roles under Security.
    2. On the Open Distro Security Roles page, click +.
    3. On the Overview tab, set Role name to role_test.
      Figure 3 Setting the role name
    4. On the Cluster Permissions tab, set cluster permissions based on service requirements. If left blank, the role will have no cluster-level permissions.
      • Permissions: Action Groups: Click Add Action Group to set cluster permissions. For example, if you select the read permission for a cluster, you can only view information such as the cluster status and cluster nodes.
      • Permissions: Single Permissions: Select Show Advanced and click Add Single Permission to set more refined permissions for the cluster. For example, indices:data/read indicates a read-only permission on specified indexes.
      Figure 4 Cluster Permissions tab
    5. Configure index permissions on the Index Permissions page.
      • Index patterns: Set this parameter to the name of the index or index pattern whose permissions you want to set. For example, my_store.

        Use different names for the index and the user.

      • Permissions: Action Groups: Click Add Action Group and set the required permissions. For example, select the read-only permission Search.
    6. On the Tenant Permissions tab, set tenant permissions.
      • Global permissions: Click Add Field to set the Kibana read and write permissions of a role, for example, kibana_all_read or kibana_all_write.
      • Tenant permissions: Click Add tenant pattern to add a tenant pattern and set the kibana_all_read or kibana_all_write permission for the new tenant pattern.
      Figure 5 Tenant Permissions tab
    7. Click Save Role Definition. Then you can view the configured role.
  7. Map a role to a user to assign permissions to that user.
    1. Click Role Mappings. On the displayed Role Mappings page, assign a role to one or more users.
    2. On the Role Mappings page, click + to select a role and add users.
      • Role: Select a role.
      • Users: Click Add User and select users you want to assign the role to.
      Figure 6 User-role mapping
    3. Click Submit.
  8. Use one of the users to which you have assigned the role to log in to Kibana. If the login is successful, the user permissions have taken effect.

Typical Example: Using the Administrator Account to Grant a User Access to Kibana

  1. Log in to a security-mode cluster as user admin.
  2. Click Roles under Security.
  3. On the Open Distro Security Roles page, click +.
  4. On the Overview tab, set the role name, for example, kibana_user.
  5. On the Tenant Permissions tab, set tenant permissions.
    • Global permissions: Click Add Field to set the Kibana read and write permissions of a role, for example, kibana_all_read or kibana_all_write.
    • Tenant permissions: Click Add tenant pattern to add a tenant pattern and set the kibana_all_read or kibana_all_write permission for the new tenant pattern.
      Figure 7 Tenant Permissions tab
  6. Click Save Role Definition. Then you can view the configured role kibana_user.
  7. On the Security page, click Role Mappings.
  8. On the Role Mappings page, click + to add the mapping between the test user and the kibana_user role.
  9. Click Submit.

    The test user now has the read and write permissions on Kibana.

Typical Example: Using the Administrator Account to Assign the Read Permission on index* to a User

  1. Log in to a security-mode cluster as user admin.
  2. Click Roles under Security.
  3. On the Open Distro Security Roles page, click +.
  4. On the Overview tab, set the role name, for example, Role1.
  5. On the Index Permissions tab, click Add index permissions.
    Figure 8 Configuring index permissions
    • Index patterns: Enter index*, meaning to set permissions for all indexes whose name starts with index.
    • Permissions: Action Groups: Select the required permissions. To set the query permission, select read. To set the write permission, select write. For a more detailed description of the permissions and the specific actions authorized, see the permissions module on the Kibana console. For example, to set the read permission, select indices:data/read* and indices:admin/mappings/fields/get*. indices:data/read* includes all permissions in indices:data/read/, including indices:data/read/get, indices:data/read/mget, and indices:data/read/search.
  6. Click Save Role Definition. Then you can view the configured role Role1.
  7. On the Security page, click Role Mappings.
  8. On the Role Mappings page, click + to add the mapping between the test user and Role1.
  9. Click Submit.

    The test user now has the read permission on index*.

Typical Example: Using the Administrator Account to Grant a User Access to the Resources of Another Tenant

The newly created test user can access Kibana and have permissions to index patterns, Discover, and Dashboards on Kibana. However, this does not mean that the test user can view any .kibana space. By default, the test user can view only the data of its private tenant space and the global tenant space. To grant it access to other tenant spaces, you need use the administrator account to assign it the required permissions through role-user mapping.

  1. Use the admin account to create index patterns and dashboards in the global tenant space of the cluster.

    All users have access to the global tenant space. When there are many departments, you can create a tenant for each department and manage users by tenant.

  2. On the Security page, click Tenants. Click + to create a tenant, for example, test_tenant.
    Figure 9 Creating a tenant
  3. Under test_tenant, create index patterns and dashboards that can be accessed by users within the department.
  4. Choose Security > Roles, click Role1, which is the role assigned to the test user, and assign test_tenant to Role1 on the Tenant Permissions tab.
  5. Save the settings. Use the test user to log in to the cluster, and see if it can access the test_tenant space.

Creating a User

Add a new user test for a security-mode cluster.

  1. After a successful login, choose Security in the navigation tree on the left of the Kibana operation page. The Security page is displayed.
    Figure 10 Accessing the Security page
  2. Choose Authentication Backends > Internal Users Database.
  3. On the Internal Users Database page, click +. The page for adding a new user is displayed.
    Figure 11 Adding a user (2)
  4. On the user creation page, specify Username, Password, and Repeatpassword, and click Submit.

    The username test is used as an example here. If created successfully, the new user is displayed in the user list.