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:
Log in to the Aiven web console and select your Elasticsearch service.
Click the ACL tab.
Switch on Enable ACL.
This creates a set of rules that grant full access (
*/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.
If you want to enforce index rules in a limited fashion for requests that use the
_bulkAPIs for this service user, switch on Enable extended ACLs.
To define new ACLs:
Click Create user ACL.
Select the service user that you want to use.
Click Add rule.
Select the permission that you want to add.
Enter the pattern for indexes that the ACL applies to.
Add more rules to the ACL if required.
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:
This set would allow the service user to
add documents to
retrieve and search documents from
gain full access to
logs_20190201(fifth rule), and
gain full access to
logs_20190115(fifth rule, as the
adminpermission gets higher priority than the
readpermission 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 to or use the API for
logs_20171230(the first rule only grants
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:
admin: no restrictions
Controlling access to top-level APIs
Elasticsearch has several "top-level" API endpoints (
_msearch, and so on), where you have to grant access separately. To do this, use patterns similar to the index patterns, for example:
_*/adminwould grant unlimited access to all top-level APIs
_msearch/admingrants unlimited access to the
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
You can switch on the
ExtendedAcl option for the service to enforce index rules in a limited fashion for requests that use the
_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:
_msearch) or switch on the
Learn how Aiven simplifies working with Elasticsearch: