Hi,
If I want to block search requests against data nodes is a simple action defintion like this sufficient:
actions: ["indices:data/read/*"]
type: deny
Or is that likely to be too heavy handed? Kibana searches come in via coordinator nodes…
The meaning of each action under each action category isn’t entirely clear.
Thx
D
Hi @cresta, please keep in mind that ReadonlyREST only polices the HTTP interface. Therefore, the plugin needs to be installed at least in the nodes that accept HTTP requests. I.e. default port 9200.
This means that if the search request comes from another node via the transport interface (default port 9300), it won’t be subject to our ACL.
This can appear like a limitation, but it’s actually an important architectural decision that guarantees that the performance of the cluster remains unaffected (unlike other solutions in the Elasticsearch security space), while we concentrate security at the boundaries with external systems (the HTTP interface).
About blacklisting specific actions/indices
I don’t know the details of the use case at hand, however in general we don’t recommend the “blacklist” approach when writing the ACL. We’d rather see everything blocked by default, and allowing only certain actions or indices instead.
The action strings, as you noticed are quite unclear. And that’s ok, because they are anyway subject to change. Imagine if in the next version of Elasticsearch they implement an alternative search mode called (i’m totally inventing this) “explore” that also returns documents as a result, and the corresponding action string will be something like “indices:data/explore/*”. Now your cluster is vulnerable and there is no way you could catch that in advance.
The whitelist approach, where you only allow certain actions to be performed, is way preferrable as you will be add allowed actions “on demand” as the user agent requires them.
An example of this is our logstash ACL block, that I paste straight from the docs examples:
- name: "::LOGSTASH::"
auth_key_sha256: "280ac6f756a64a80143447c980289e7e4c6918b92588c8095c7c3f049a13fbf9" #logstash:logstash
actions: ["cluster:monitor/main","indices:admin/types/exists","indices:data/read/*","indices:data/write/*","indices:admin/template/*","indices:admin/create"]
indices: ["logstash-*"]
Notice the long, specific list of actions which were extracted simply by letting Logstash run and adding an action string every time we observed a rejected request in the ES logs.