CODEWITHSUNDEEP
elasticsearchelasticsearch-plugin
dingjun
dingjun

Reputation: 94

single permissions in search guard

I went through the latest documentation of search guard, https://docs.search-guard.com/latest/roles-permissions and could only find a short explaination for single permissions:

Single permissions either start with cluster: or indices:, followed by a REST-style path that further defines the exact action the permission grants access to.

So one permission could be on cluster level or on indices level.

indices:data/read/search

So the part before : could be indices or cluster, but I'm not clear how to understand the parts after semicolon, and what are these parts seperated by "/".

Can someone please explaine me more about this or point me to some documentation, which I maybe missed?

Thanks

Dingjun

Upvotes: 1

Views: 473

Answers (1)

Jochen Kressin
Jochen Kressin

Reputation: 386

This is actually not related to Search Guard but to Elasticsearch. When you interact with Elasticsearch, e.g. indexing data or searching data, what you are really doing is executing actions. Each action has a name, and this name is in the format you outlined.

For example, have a look at org.elasticsearch.action.search.SearchAction:

public class SearchAction extends Action<SearchRequest, SearchResponse, SearchRequestBuilder> {

public static final SearchAction INSTANCE = new SearchAction();
public static final String NAME = "indices:data/read/search";

private SearchAction() {
    super(NAME);
}
...

}

The permission schema of Search Guard is based on these Elasticsearch action names. So the naming conventions is actually an Elasticsearch naming convention.

Elastic does not publish a list of these action names anymore. AFAIK in X-Pack Security you cannot actually go down to this level of detail regarding permissions, that's probably why they stopped to do so.

The Search Guard Kibana plugin comes with a list of permissions you might use as a guideline:

https://github.com/floragunncom/search-guard-kibana-plugin/blob/6.x/public/apps/configuration/permissions/indexpermissions.js

https://github.com/floragunncom/search-guard-kibana-plugin/blob/6.x/public/apps/configuration/permissions/clusterpermissions.js

The question is if you really need to implement security on such a fine-grained level. That's what the action groups are for. These are pre-defined sets of permissions and should cover most use cases. Also, they are updated with each release if the permissions in Elasticsearch change, so it's safer to use action groups than to rely on single permissions. But as always, it depends on the use case.

Upvotes: 2

Related Questions