Note: Aiven for OpenSearch replaces Aiven for Elasticsearch after Elasticsearch version 7.10.2 due to licensing changes. In addition, OpenSearch Dashboards replaces Kibana. Starting from September 24th, 2021 until March 23rd, 2022, Aiven supports services running both OpenSearch and Elasticsearch 7.10.2. For more information on Aiven for OpenSearch, see our developer documentation.

Aiven for Elasticsearch supports index-level access control lists (ACL) to control permissions.

To define ACLs for your service:

  1. Log in to the Aiven web console and select your Elasticsearch service.

  2. Click the ACL tab.

  3. Switch on Enable ACL.
    This creates a set of rules that grant full access (_*/admin, */admin) for each existing service user.

    Note: After you switch on ACL support, the service does not automatically add an ACL for new service users that you add. By default, access is denied.

  4. If you want to enforce index rules in a limited fashion for requests that use the _mget, _msearch, and _bulk APIs for this service user, switch on Enable extended ACLs.

  5. To define new ACLs:

    1. Click Create user ACL.

    2. Select the service user that you want to use.

    3. Click Add rule.

    4. Select the permission that you want to add.

    5. Enter the pattern for indexes that the ACL applies to.

    6. Add more rules to the ACL if required.

    7. Click Create.

Basic access control

You can grant the following permissions:

  • deny: no access

  • admin: full access to APIs and documents 

  • readwrite: full access to documents

  • read: allow only searching and retrieving documents

  • write: allow updating, adding, and deleting documents

Rules are defined separately for each user as pattern/permission combinations. The pattern defines the indexes that the permission applies to. Patterns are glob-style, where * matches any number of characters and ? matches any character. 

When multiple rules match, they are applied in the order listed above. If no rules match, access is denied.

As an example, we can use the following set of rules:

  • logs_*/read

  • events_*/write

  • logs_2018*/deny

  • logs_201901*/read

  • logs_2019*/admin

This set would allow the service user to

  • add documents to events_2018 (second rule),

  • retrieve and search documents from logs_20171230 (first rule),

  • gain full access to logs_20190201 (fifth rule), and

  • gain full access to logs_20190115 (fifth rule, as the admin permission gets higher priority than the read permission in the fourth rule.

The same set would deny the service user to

  • gain any access to messages_2019 (no matching rules),

  • read or search documents from events_2018 (the second rule only grants write permission), and

  • write to or use the API for logs_20171230 (the first rule only grants read permission).

Note: Write permission allows the service user to create new indexes that match the pattern, but it does not allow deletion of those indexes.

The permission also implies which index APIs the service user can access:

  • read:  _search, _mget

  • write: _bulk, _mapping, _update_by_query, _delete_by_query

  • admin: no restrictions

Controlling access to top-level APIs

Elasticsearch has several "top-level" API endpoints (_mget, _msearch, and so on), where you have to grant access separately. To do this, use patterns similar to the index patterns, for example:

  • _*/admin would grant unlimited access to all top-level APIs

  • _msearch/admin grants unlimited access to the _msearch API only

In the Aiven web console, this would look like the following in the ACL > Create user ACL > Add rule view:

Note: You might encounter HTTP 500 internal server errors when you try to view dashboards as a service user that has read-only access to certain indexes, as these dashboards call the _msearch API. In such cases, add a new ACL rule that grants Admin access to _msearch for that service user. The following screenshot shows an example of the error when loading dashboards:

Only rules where the pattern starts with _ are considered for top-level API access. Normal rules do not grant access to these APIs. For example, *search/admin only grants access to indexes that match the pattern, not to _msearch.

You can switch on the ExtendedAcl option for the service to enforce index rules in a limited fashion for requests that use the _mget, _msearch, and _bulk APIs (and only those). When this option is in use, service users can access these APIs as long as all operations only target indexes that they have appropriate permissions for. 

Note: To enforce the rules with ExtendedACL, the service must inspect the content of the request, which can cause performance and latency issues. All requests are also limited to a maximum of 16 KiB in size. If the request is too large or if any of the operations or indexes are not allowed, the entire request is rejected.

Access control and aliases

Aliases are not expanded. If you use aliases, the ACL must include a rule that matches the alias.

Access control and Kibana

Enabling ACLs does not restrict access to Kibana itself, but all requests done by Kibana are checked against the current user's ACLs. 

In practice, for Kibana to function properly, you must grant the user admin-level access to the _msearch interface (permission: admin, pattern: _msearch) or switch on the ExtendedAcl option.

Learn how Aiven simplifies working with Elasticsearch:

Did this answer your question?