Elastic provides role-based access control and external authentication capabilities in the GA version of ECE 2.3

The authors Rory Hunter,

We are pleased to announce that role-based access control and external source authentication are now available with the release of Elastic Cloud Enterprise (ECE) 2.3. Through these features, you can have multiple users whose ECE platform access is controlled by roles. You can add users locally in ECE and connect to your own directory server or identity provider to grant access to existing users.

We initially added open beta support for these features in ECE 2.2. In addition to removing a number of bugs in version 2.3, we have added support for Active Directory and existing LDAP and SAML options.

How does it work?

Enabling RBAC for ECE adds a security deployment, which is a system deployment that manages all authentication configurations and permissions. ECE will use this security deployment to perform authentication when a user attempts to log in and back to the system user as appropriate. If a user successfully authenticates, ECE applies the roles assigned by the user and translates them into fine-grained permissions that control what data each user can view and what actions they can perform.

Note that a user’s ECE role is separate from any credentials that the user retains for deployments hosted in ECE. Users may not have access to ECE, but may have administrative access to managed deployments, and vice versa.

What roles are available?

ECE provides a rich set of operations at the platform and deployment levels. To ease the task of administrators in defining and maintaining their own role definitions, ECE provides a set of predefined roles that cover the most common use cases. These roles will be constantly updated as more features are delivered, so you don’t have to worry about keeping your definitions up to date.

The roles are described below. Users can have multiple roles and combine them as needed; for example, a “platform administrator” can perform any action, so there is no need to provide them with other roles. However, Platform Viewer can view anything but cannot change it, so you might use it in combination with the Deployment Manager role.

Platform manager

Through this role, the user is able to view all data and perform any action in ECE in the same way as the system-level admin user (or root in ECE 1.x) created during installation. This role is typically held only by the administrator responsible for the entire ECE platform. The “Platform” section of the UI is a good example, as it provides information about (for example) allocators and their deployment, and can vacate the allocator or put it in maintenance mode.

Platform Viewer

This role provides view-only access to the entire platform and managed deployment. The associated permissions are the same as those held by ReadOnly system-level users. This is useful for automation, such as monitoring the status of ECE.

Deployment manager

This role allows users to create and manage deployments on the platform. A user with this role can do anything about the deployment: expand, shrink, configure snapshots, restart nodes, reset passwords, and so on, but it does not allow the user to access any platform-level actions and resources, such as deployment templates, instance configurations, allocators, and system deployments.

This role applies to anyone who is responsible for managing the deployment but does not need to see platformer level information, such as the development team lead.

Deployment Viewer

Users with this role can view the deployments but cannot modify them in any way. This role applies to support staff or development team members.

Manage local users

The easiest way to start using RBAC in ECE is to create a native user. These users will be kept in a secure deployment within Elasticsearch Native Realm, and only a limited number of properties are supported: username, full name, email, password, role, and whether they are currently enabled.

Click “User” in the navigation menu to view your authentication providers, one of which is the “Native Users” (Native User) profile. Opening this configuration file takes you to a list of all native users. This list includes two system users created by ECE installer. These users cannot edit or delete, and their passwords cannot be reset here. See the documentation for more instructions on how to reset passwords.

On the Native Users page, you can create, edit, and delete Native users. These users can log on to ECE just like system users, and their access is controlled according to the role you assign to them.

User Settings Page

ECE 2.3 also adds a “User Settings” page. Click the user icon in the upper right corner of the page, and then click “Settings.” If you are logged in as a native user, you can edit your name and email, or change your password. If you log in as a user from an external authentication provider, you will see a read-only page that contains some basic information, the name and type of the authentication profile, and the roles you have.

External authentication provider

If you already have LDAP, Active Directory, or SAML servers, ECE can be configured to use them for authentication and authorization. You can even configure multiple servers and try authentication in the same order you set it up in the same way as Elasticsearch. Using an existing authentication source means that you only have to manage users in one place. The role mapping configuration for external providers allows you to map user attributes to roles in ECE, so any changes to user attributes (such as group membership) are automatically captured by ECE.

On the authentication provider overview page, click Add Provider and select a type. On the next page, you will configure the provider. Let’s step through the configuration options for the basic LDAP setup.

LDAP authentication provider

General Settings:

  1. Each configuration file has a name. In addition to using it to mark configuration files, this name is also used to generate a Realm ID. Note that the Realm ID will not change once the configuration file is created.
  2. You must set up at least one LDAP server, including the initial oneldap: 或 ldaps:The agreement. If you choose a DNS based load balancing strategy, you can only specify a single server.
  3. Keep the above limitations in mind when choosing a load-balancing strategy.

Trusted certificate:

  1. If your LDAP server is protected in such a way that clients need to hold specific SSL/TLS certificates, you need to prepare the bundle file and provide it to ECE via the URL. For more detailed information, see the documentation.
  2. If your bundle is password protected, please provide your password here.

Binding credential:

  1. If credentials need to be bound to the LDAP server, you can set them up here.
  2. Alternatively, if credentials are not required, click the “Bind Anony6” (anonymous binding) tog6 button.

Search mode Settings:

  1. You can specify each item of detail for the user’s search. See the documentation for information on these fields. At a minimum, you might want to set “Base DN for users” (the user’s Base DN), such as “cn=users,dc=example,dc=com”.
  2. Or, if you need to use a Template to perform an LDAP query, click the “Template” (Template) radio button and provide one or more templates.

Group search Settings:

  1. Much like the search mode Settings, you can configure how ECE should search for user groups. You may need to set “Base DN for groups” (the Base DN for a group), such as “ou=groups,dc=example,dc=com”.

Role mapping:

  1. Users need to have one or more personas to perform any action through ECE. For all users who successfully authenticate, you can specify some default roles that will be assigned to them. For example, you can grant all users the role of “Deployments Viewer” so that they can view all the Deployments hosted in ECE without being able to edit anything.
  2. Another way to assign roles is through role mapping. These are simple rules that indicate that one or more specified roles will be assigned if the user DN or group DN matches a value. You can have as many mappings as you need, for example, a “Deployment Viewer” mapping for IT OPS users, a “Deployment Manager” mapping for all developers, And provide a “Platform Viewer” mapping for all administrators.

When this is done, click Create Profile and ECE reconfigures the security deployment. You should now log in with the various LDAP users to check that they are authenticated and that their roles are correct. You can check the roles directly from the user Settings page, or you can browse the UI to ensure that what they are able to see and do is as expected.

Active Directory and SAML authentication provider

In a nutshell, this process is similar to LDAP from an ECE perspective. You can create a SAML or Active Directory authentication provider, give it a name, specify how ECE should communicate with the server, and define the mappings that should apply.

See the documentation for complete instructions on configuring the SAML authentication provider or Active Directory authentication provider.

REST API support

All of the above operations can also be performed using the REST API. For example, to extract a list of all users, even those currently disabled:

GET /api/v1/users? include_disabled=true

Suppose you need to grant permissions to a new system administrator, Sarah. You can create a new native user for her as follows:

POST /api/v1/users { “user_name”: “sarah”, “security”: { “roles”: [“ece_platform_admin”], “password”: “deadb33f” } }

If you then want to change Sarah’s access, you can send a PATCH request containing only the fields you want to change, in this case the role is:

PATCH /api/v1/users/sarah { “security”: { “roles”: [“ece_platform_viewer”] } }

Finally, you can DELETE Sarah’s account using the DELETE request:

DELETE /api/v1/users/sarah

Refer to the REST API documentation for details and examples of authentication provider endpoints.

Start using now

For a complete list of changes in ECE 2.3, be sure to see the release notes. If you want to try it yourself, you can start a free 30-day trial right away.

To learn more about Elastic technology, please follow and sign up for the webinar. The upcoming schedule is as follows:

Wednesday, February 19, 2020 15:00-16:00 Building Omni-Observable Instances Using Elastic Stack

Wednesday, February 26, 2016 15:00-16:00 Kibana Lens Webinar

Wednesday, March 4, 2020 15:00-16:00 Elastic Endpoint Security Overview Network

Monitor website resources with Elastic Stack Wednesday, March 11, 2020 15:00-16:00