6df767790f
We have two ways of resolving wildcards in shield: 1) expanding them to matching authorized indices for the current user, which is used for every request that implements `IndicesRequest.Replaceable`, giving to wildcards a different meaning in the context of shield, abnd replacing the resolved names to the request on the coordinating node. 2) resolving them as es core would by default: we do this only for `IndicesAliasesRequest` since it's the only request that supports wildcards but doesn't allow to replace its indices. This is done on every node that processes the request, no replacement to the request takes place. Shard/node level requests are a bit of a special case though since they could potentially contain wildcards. They hold the original indices and indices options, thus they effectively support wildcards, but given that wildcards always get replaced on the coordinating node even before shard/node level requests get created, we are sure they will never contain wildcards. Hence we should never even try to explode their wildcards, since they can't contain any. We should make the above distinctions clearer in code by: 1) having an assert that verifies the IndicesAliasesRequest special case 2) making sure that we explode wildcards as core would only for IndicesAliasesRequest, not touching shard/node level requests 3) adding an assert that verifies that shard/node level requests never contain wildcards i Also, the process of going over the indices by using MetaData#convertFromWildcards (what option 2 does) has one side effect other than wildcards resolution: it causes unnecessary exceptions in shield, exceptions that would be thrown by core anyway when needed after the authorization process. This happens because we try and reuse code taken from es core that does wildcards resolution plus indices validation at once (even if there were no wildcards among indices). In general all of the user requests that support wildcards (based on their indices options) should have their indices replaced on the coordinating node (the only exception being IndicesAliasesRequest, see elastic/elasticsearch#112), using shield specific code. Their subsequent (internal) shard level requests will never contain wildcards. That's why there is no need to go over all of the indices when there's no wildcards, which would cause some needless validation to happen as well. Side note: the additional validation step caused tribe node failures with requests against indices belonging to multiple tribes (the exact purpose of the tribe node). Each tribe complained because it didn't have all of the indices in its own cluster state, which is perfectly fine (think of `tribe1` that holds `index1` and `tribe2` that holds `index2`, when searching against both indices from a tribe node). Although this commit makes sure that we don't throw any index missing exception for indices that are not available, all of the tribes will still need to authorize the action on all of the indices (`tribe1` requires privileges for `index2` so does `tribe2` for `index1`, otherwise the shard level requests will get rejected. Closes elastic/elasticsearch#541 Original commit: elastic/x-pack-elasticsearch@dd81ec0177 |
||
|---|---|---|
| dev-tools | ||
| src | ||
| LICENSE.txt | ||
| README.asciidoc | ||
| TESTING.asciidoc | ||
| all-signatures.txt | ||
| core-signatures.txt | ||
| pom.xml | ||
| test-signatures.txt | ||
| tests.policy | ||
README.asciidoc
= Elasticsearch Security Plugin This plugins adds security features to elasticsearch You can build the plugin with `mvn package`. The documentation is put in the `docs/` directory.