Aiven for Elasticsearch now supports index level ACLs for controlling permissions. You can define ACLs via the web console of your Elasticsearch service.
When access control is initially enabled for the service, a set of rules (_*/admin, */admin; granting full access) is created for each existing service user.
NOTE! After ACL support has been enabled, adding a new service user will not automatically add an ACL for that user and by default access is denied.
Selecting the Add new ACL allows you to create the required rules.
Basic access control
You can grant the users 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. The pattern defines the indexes the permission is applied 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, the access is denied.
For example the following rules
- adding documents to events_2018 (rule 2)
- retrieving and searching documents from logs_20171230 (rule 1)
- full access to logs_20190201 (rule 5)
- full access to logs_20190115 (rule 5, admin grant is higher than read (rule 4))
but would deny
- all access to messages_2019 (no matching rules)
- reading or searching documents from events_2018 (rule 2, only write permission)
- writing or API use of logs_20171230 (rule 1, only read permission)
Note! write permission will allow creating new indexes matching the pattern but it will not allow deleting those indexes.
The permission also implies which index APIs the 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 access to these have to be separately granted. This is done by using patterns similar to the index patterns. For example a rule "_*/admin" would grant unlimited access to all the top level APIs.
Only rules where the pattern starting with '_' are considered for top level API access, normal rules will not grant access to these APIs. "*search/admin" only grants access to indexes matching the pattern, not to _msearch.
Index rules can be enforced in a limited fashion to requests using the _mget, _msearch and _bulk APIs (and only those) by enabling the ExtendedAcl option for the service. If enabled, users can access these APIs as long as all operations only target indexes they have appropriate permission for.
NOTE! To enforce the rules with extendedACL, the content of the request needs to be inspected and this can introduce performance and latency issues . All requests are also limited to maximum of 16 kiB in size. If the request is too large or any of the operations or indexes are not allowed, the whole request will be rejected.
Access control and aliases
Aliases are not expanded and if used, the ACL must include a rule matching the alias.
Access control and Kibana
Enabling ACLs does not restrict access to kibana itself, however all requests done by kibana will be checked against the effective user's ACLs.
In practice, for kibana to function the user must be granted access to the _msearch interface (via rule "_msearch/admin") or extendedAcl to be enabled.