Runtime index privilege evaluation
This chapter takes a closer look at how Search Guard applies the configured privileges to actually executed operations in Elasticsearch.
Handling references to unauthorized indices
There are several ways how the privileges of a user can be applied to operations performed by that user:
In the simplest cases, it is a yes/no decision: If a user has the necessary privileges, the operation succeeds and the user gets a
200 OKresult (or similar). On the other hand, if a user does not have the necessary privileges, the operation is not performed and the user receives a
However, depending on the type of operation, the result might be more gradual: Take for example search operations on index patterns (such as the wildcard
*, which searches all indices). By default, Search Guard will make all indices for which the user does not have privileges, “invisible” to the operation. This means that a search on the index pattern
*will only return results for indices the user is allowed to see. If a user does not have access to any indices that are matched by the pattern, the user will get a search result with zero search hits. This gradual application of index privileges is also referred to as the
ignore_unauthorizedmode. The name was chosen following the
ignore_unavailableindex option of Elasticsearch, which has a similar goal and operates with similar semantics.
ignore_unauthorized mode of Search Guard is configurable to a certain extent and is described more in detail in the following sections. If you do not want Search Guard to reduce the searched indices based on privileges, you can turn this feature completely off by setting
sg_authz.yml. However, we are not recommending this mode of operation, as disadvantages clearly outweigh advantages.
Note: Older versions of Search Guard had a similar feature called
ignore_unauthorized mode has broader support for operations and refined semantics.
Rules for ignoring of unauthorized indices
Search Guard applies the
ignore_unauthorized treatment only under a set of conditions:
ignore_unauthorizedmode is enabled.
One of the supported operations is executed. Search Guard supports operations of Elasticsearch which support index patterns or operate on all indices on the cluster. Furthermore, Search Guard provides configuration options to control what operations shall be affected by the
- The request refers to indices using a pattern (like
index_*) OR has the index option
ignore_unavailableactivated. If you are using the REST API directly, you can activate this option by appending
?ignore_unavailable=trueto the URL.
If you choose to disable the
ignore_unauthorized feature, there are a couple of things to take care of:
- Operations referencing
*will also apply to the legacy
searchguardindex, if it exists. As normal users are normally not allowed to access this index, you will get
403 Forbiddenerrors for operations referencing
*. This can be avoided by migrating the
searchguardindex to a hidden index called
.searchguard. See TODO for details on how to perform this migration.
- Kibana will only work properly for users with full access. Users having access to only a subset of indices will get lots of error messages within Kibana.
Index alias handling
Before applying any security checks, Search Guard first resolves any alias to the concrete index name(s). Index aliases are thus transparent to Search Guard. The same is true for
- Index wildcards, also with multiple index names
- Date math index names
- Filtered index aliases
In practice this means that you do not need or can grant permissions on index aliases. You just need to grant permissions on actual index names. For example, if you have an index alias
myalias pointing to an index
myindex, you only need to configure permissions for
myindex. These permissions apply regardless whether the user accesses the index via