Manage users and roles in Shieldedit

For versions before 5.0: You configure users, their roles, and the roles themselves in the Cloud UI Shield user editor, accessible on the Security page for each deployment.

The Shield Editor


Defines the users in your cluster. A user entry consists of a username and a password hash.

To add a new user:

  1. In the editor, add a new line with the username and a clear text password in the format username: password. Keep the password in a secure location.

    A valid role or user name must be at least 1 character and no longer than 30 characters. It must begin with a letter (a-z) or an underscore (_). Subsequent characters can be letters, underscores (_), digits (0-9) or any of the following symbols @, -, . or $.

  2. Click Save to hash the password and save the updated Shield configuration.

If you do lose a password, you can enter a new password for the user and resave the Shield configuration. The same applies to passwords that you need to reset: Enter a new password and save the configuration.

If you already use Shield with a cluster running on your own servers, you can simply copy the config/shield/users file and paste it in this editor. For example:

# Lines starting with # are comments.
# This file expects usernames to map passwords or hashes, like the following:
elastic: $2a$12$uRopB3Jz3slQQVMUTlNuPeHRhbfbFWDBrXhRk8vzK7xr0mavw2vAq

# This password has not been hashed yet, but will be when you save.
my_user: bc3rqc0q1xwr4irq3o

To delete a user:

  1. Remove the user from the editor.
  2. Click Save to save the updated Shield configuration.

Users per Roleedit

Maps roles to users. A user can have several roles, and a role can have several users.

To modify the mapping of roles to users:

  1. Either add a user name to an existing role or add a new role and specify which users hold that role. The format is role-name: user1, user2, .... Each role is specified on a separate line.
  2. Click Save to save the updated Shield configuration.

For example:

# The users per role file maps roles and users like this:
# role_name: user1, user2

admin: elastic
readonly: my_user, anonymous


Customize which actions users with the role can perform, both on a cluster and an index level.

To learn more, see configuring role-based access control is available in the Shield documentation.

You can use the default roles or adapt them. Here are two examples of roles with comments that indicate what permissions these roles grant:

# Admins can do everything
  # If you use a generic group of actions, such as "all", "read", "monitor", etc.
  # you can simply specify the group without listing every action.
  cluster: all
    # The same is true for indices. You can also list aliases here.
    # Note that the index name '*' is quoted. This is because this is actually
    # a YAML file, and the * character can have a special meaning. It is a good
    # practice to quote all the index names.
    '*': all

# This is an example of a role with more granular access. We explicitly list
# every action possible, both on the cluster and the indicies.
# A user with this role will be able to use Kibana 4 and read the indices
# logs-* and even-more-logs-*. Dashboards/Visualizations can be modified
# but the indices being analyzed can only be read.
      - cluster:monitor/nodes/info
      - cluster:monitor/health
      # Note that we use a list here. Every action is indented and
      # starts with `- `.
      - indices:admin/mappings/fields/get
      - indices:admin/validate/query
      - indices:data/read/search
      - indices:data/read/msearch
      - indices:admin/get
      - indices:admin/exists
      - indices:admin/mapping/put
      - indices:admin/mappings/fields/get
      - indices:admin/refresh
      - indices:admin/validate/query
      - indices:data/read/get
      - indices:data/read/mget
      - indices:data/read/search
      - indices:data/write/delete
      - indices:data/write/index
      - indices:data/write/update
      - indices:admin/create