Compliments and a question

jacobbogers · November 17, 2018, 11:40pm

FIRST MY COMPLIMENTS!
Wonderfull plugin, after struggling to get xpack working your plugin is really a breeze to use
I work for company that is tryingout your plugin for internal enterprise use (need to protect certain data on field and document leve).

Your plugin is really straightforward to configure and use. kiddos

SO far I have encryption enbaled on elastic search and reading through your ACL list

MY QUESTION:
I am not an elastic stack veteran, I read the docs last year, and now actively making an MVP and started with 6.4.3

I have never seen this “action” strings before described here, (link)

github.com

beshu-tech/readonlyrest-docs/blob/master/elasticsearch.md#actions

# For Elasticsearch

## Overview: The ReadonlyREST Suite

ReadonlyREST is a light weight Elasticsearch plugin that adds encryption, authentication, authorization and access control capabilities to Elasticsearch embedded REST API. The core of this plugin is an ACL engine that checks each incoming request through a sequence of **rules** a bit like a firewall. There are a dozen rules that can be grouped in sequences of blocks and form a powerful representation of a logic chain.

The Elasticsearch plugin known as `ReadonlyREST Free` is released under the GPLv3 license, or alternatively, a commercial license \(see [ReadonlyREST Embedded](https://readonlyrest.com/embedded)\) and lays the technological foundations for the companion Kibana plugin which is released in two versions: [ReadonlyREST PRO](https://readonlyrest.com/pro) and [ReadonlyREST Enterprise](https://readonlyrest.com/enterprise).

Unlike the Elasticsearch plugin, the Kibana plugins are commercial only. But rely on the Elasticsearch plugin in order to work.

For a description of the Kibana plugins, skip to the [dedicated documentation page](kibana/) instead.

### ReadonlyREST Free plugin for Elasticsearch

In this document we are going to describe how to operate the Elasticsearch plugin in all its features. Once installed, this plugin will greatly extend the Elasticsearch HTTP API \(port 9200\), adding numerous extra capabilities:

* **Encryption**: transform the Elasticsearch API from HTTP to HTTPS
* **Authentication**: require credentials
* **Authorization**: declare groups of users, permissions and partial access to indices.
* **Access control**: complex logic can be modeled using an ACL \(access control list\) written in YAML.

This file has been truncated. show original

you also refer to elasticsearch 5.1.2. explicitly, so do these strings not exist anymore in 6.4.3??

are these actions relevant in the current 6.4.3 version.???

sscarduzio · November 18, 2018, 6:01am

Hello @jacobbogers, and thanks for the kind words!
The set of existing actions does not change between the ES versions. But when they add a new feature in ES they add an action string for it.

jacobbogers · November 18, 2018, 6:49pm

forgive my noob question, what is an “action”,I am diving in the elastic docs but dont see it,
is this part of the search api?

sscarduzio · November 19, 2018, 1:38am

An action is like a the name of an internal function you can invoke inside ES. You can invoke it either via HTTP (port 9200), or via ES transport protocol (port 9300).

You don’t find anything in the ES docs because it’s a concept that they don’t expose to the public API, however the names are pretty descriptive and invariant across time, so they became part of the ReadonlyREST API.

The good news is that we also created a macro rule called kibana_access that identifies the actions required for a ‘rw’, ‘ro’, and ‘ro_strict’ Kibana session.

We also provide examples of the minimum set of actions to be allowed in order for Logstash and Metricbeats to work correctly

jacobbogers · November 19, 2018, 10:43am

I put “kibana_access” to “ro”
will it

will it still create this monitoring indices? like (examples) .monitoring-alerts-6, .kibana, .monitoring-kibana-6-2018.11.13 ,.watches, .triggered_watches, ..watcher-history-9-2018.11.13
?
will kibana user be able to delete/create/alter indices from the “dev tool” tab, if kibana_access: ro?

sscarduzio · November 20, 2018, 6:50am

ROR polices the HTTP interface, the creation of monitoring indices happens X-Pack ES plugin. So ROR does not even see those indices being created.

Absolutely not. As I said, the access control is done in Elasticsearch HTTP interface, so what you can do from dev tools as a RO user will be limited to the set of actions you can perform during a normal RO Kibana session (mainly searches).

jacobbogers · November 20, 2018, 9:12am

Absolutely not. As I said, the access control is done in Elasticsearch HTTP interface, so what you can do from dev tools as a RO user will be limited to the set of actions you can perform during a normal RO Kibana session (mainly searches).

Fantastic!!!