Include actions references in Wiki

[juansaavedrauy]

I've been trying to understand the possible values for the actions field in the Supported Rules page and by reviewing the code, both of the plugin and ES.

Is this value specific to the data, as the indices are? Or does it refer to the diferent APIs and actions in the elastic search docs?If it's the latter, it would be great to have a list or something.

In the code I see that it picks it up from the ActionRequest in the RequestContext, but I'm unable to follow what kind of actions are defined in ES.

I'm a bit new around ES, so this might be something I'm missing as a rookie.

Thanks.

[sscarduzio]

You're totally right, myself I had the same question. The actions are defined somewhere in ES code, and what they mean is not well documented. But they can be audited using logs when you use a particular app.

You should see the toString of RequestContext being logged when ES is in debug mode if I recall correctly..

You can see an example of what actions I needed to let through to support Kibana (ref. KibanaAccessRule class) that list comes from the official docs on how to configure Shield for Kibana.

It's not much info, but I hope it helps. Probably if you share more on what is your objective I could be more helpful:)

On 6 Apr 2016, at 19:45, Juan Saavedra notifications@github.com wrote:

I've been trying to understand the possible values for the actions field in the Supported Rules page and by reviewing the code, both of the plugin and ES.

Is this value specific to the data, as the indices are? Or does it refer to the diferent APIs and actions in the elastic search docs?If it's the latter, it would be great to have a list or something.

In the code I see that it picks it up from the ActionRequest in the RequestContext, but I'm unable to follow what kind of actions are defined in ES.

I'm a bit new around ES, so this might be something I'm missing as a rookie.

Thanks.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[juansaavedrauy]

Thanks for the prompt response. I will start to look into the logs.

I want to provide a set of API keys to:

• A master key with allow all.
• A write key that will allow CRUD operations on documents.
• A read key.

From what I see in the docs, this could be something like

readonlyrest:
    enable: true
    response_if_req_forbidden: Forbidden!
    access_control_rules:
    - name: Master
      type: allow
      api_keys: [masterkey]

    - name: Write
      type: allow
      api_keys: [writekey]
      actions: [indices:data/*]

    - name: Read
      type: allow
      api_keys: [readkey]
      actions: [indices:data/read/*]

However, I don't know (yet) if this allows to search for the requests with the Read key.

[sscarduzio]

It should: if you come with a read action, the first two blocks won't match, so the third is evaluated and matched a "allow".

I'd add to the allowed actions also the "search*", as I see search as a form of read (unless it's the wanted behaviour).

On this note, I saw the latest version of Shield can be configured in terms of a smaller set of "privileges" that can be seen as macro groups of actions. This makes it much easier to configure, and I'd like to follow their example.

[juansaavedrauy]

I'm finishing up some tests and it should be enough, I'm planning to leave what I can found on the wiki.

Another concern was the bulk operations, but it is covered by actions.

The best way I've found to see the actions is to create an ACL rule with an actions: item, and send a requests that matches. Then, the logging system at es-readolyrest logs the received action.

Do you have any references to the Shield privileges?

[sscarduzio]

@elpaquete please know your contribute on this topic is very much needed and appreciated. So many thanks for doing this.

Unfortunately, Shield's documentation is incomplete when it comes to give a meaning to privileges in terms of actions. And what's even worse is that Shield's license is not open source. This prevents us from independently investigating any detail behind what their definition of privileges mean (in term of actions).

Also it makes me mad they're preventing a knowledgable community of users from making Shield better, but this is another level of OSS vs proprietary software rant :)

The best I came across so far is this page defining in words all possible Shield privileges and what they're supposed to mean:

https://www.elastic.co/guide/en/shield/current/shield-privileges.html

[juansaavedrauy]

I've updated the supported rules page to include what we've found testing different operations.

For our current purposes, the configuration from a previous message works as desired. The search action is beneath the data/read action.

Maybe this issue can be closed now.

[sscarduzio]

Well done @elpaquete, your wiki is a gold mine! Very useful. Once again, thanks, I'll close the issue.

[juansaavedrauy]

@sscarduzio No problem.

I've found this project quite useful, I'll keep an eye on it although ES and Java are quite out of my track.

We are cooking some Docker images with some configuration files, I'll keep you posted.

[sscarduzio]

Yeah by all means, if you are able to share your experience in form of Dockerfile + conf files this would be pure gold for the project and its users 👍 Looking forward to hearing from you!

[juansaavedrauy]

A first approach is available at https://hub.docker.com/r/octobotdev/elasticsearch-readonlyrest/

I'll later upload the files to Github. This is the Dockerfile

FROM elasticsearch:2.3.1
MAINTAINER Juan Saavedra <jsaavedra@octobot.io>

RUN bin/plugin install https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/blob/master/download/elasticsearch-readonlyrest-v1.9.1_es-v2.3.1.zip?raw=true
ADD readonlyrest-config.yml config/readonlyrest-examples/
ADD replace_keys.sh scripts/
RUN cp config/elasticsearch.yml config/elasticsearch.yml.orig

We've found it to be quite useful like this, hopefully its helpful :ponies: