Version 5.0 and later, manage users and roles in X-Packedit

You work with users and roles in the Kibana Management app, accessible from the Security page in the Elasticsearch Service Console or directly from the Kibana side navigation.

The Users tab shows the users that have been configured on your deployment. You can add or delete users here and assign roles that give users specific privileges. A user can be assigned multiple roles.

The <code class=admin user in X-Pack">

If you upgraded your deployment to Elasticsearch 5.0 or later from a version before 5.0, the users defined in Shield were also migrated to X-Pack and show up in this list. This includes the default admin, readwrite, and readonly users, which you can work with like any other user in the Kibana Management app.

The Roles tab shows the roles that exist on your deployment. Roles let you customize exactly which actions a user with the role can do, both on a deployment and an index level. Several users can have the same role. You can also add or delete users.

The <code class=admin role in X-Pack">

Two users are always created with new version 5.x deployments:

A superuser that is somewhat similar in scope to the default admin user in Shield configurations in Elasticsearch Service before version 5.0. The elastic user is not shown in the Kibana Management app and you cannot modify this user, other than to reset the password.
A user for handling incoming requests where no authentication token can be extracted. By default, this user has no privileges. It is NOT recommended to provide any privileges to that user and role, and as a best practice you should NOT enable anonymous access for production environments. In Elasticsearch versions 7.10 and higher, the anonymous user is disabled by default. If your use case requires unauthenticated access, you can enable it by adding the* setting to the elasticsearch.yml file. In versions prior to 7.10, you can add the setting to prevent anonymous access being accidentally disabled by a subsequent upgrade. For details, see enabling anonymous access.

To learn more about users and roles, see User authentication.

Example: Create a Filebeat role and useredit

To send Beats data to a secured cluster in Elasticsearch Service, you should use a user that has the right privileges. When we showed you a Beats example that configured Filebeat on a server to send data to Elasticsearch Service, the user filebeat_internal was used.

To create a similar user and role in the Management app in Kibana:

  1. Log in to the Elasticsearch Service Console.
  2. Select your deployment on the home page in the Elasticsearch Service card or go to the deployments page.

    Narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list.

  3. From your deployment menu, go to Kibana and open the Kibana endpoint.
  4. From Kibana, go to the Management app.
  5. Select the Roles tab, click New Role and give the role the filebeat-writer name.
  6. Specify the right privileges. Under Cluster Privileges, select monitor and manage_index_templates. Under Indices Privileges, specify read, write, and create_index privileges for the filebeat-* indices that the Beat creates.

    The `filebeat-writer` role
  7. Click Save.
  8. Select the Users tab, click New User and give the user the filebeat_internal name.
  9. Assign the filebeat-writer role to the user under Roles.

    The `filebeat-internal` user
  10. Enter a password and confirm the password. Make a note of the password and keep it in a secure location.
  11. Click Save.

After the user and role are saved, you can use the new user to authenticate when sending data from Filebeat to your cluster.