REST APIs access permission control for different users based on https://github.com/opendistro-for-elasticsearch/security

[jngz-es]

Hi,

I am creating this issue to discuss a feature about users permission control for the below three scenarios.

1. For each REST API, check user's permission if they are allowed to access this API.
2. A user cannot access another user's data, like models, feature sets etc.
3. Users cannot access LTR indices directly.

We'd like to provide this feature by integrating with https://github.com/opendistro-for-elasticsearch/security. Basically we would associate each REST API with a transport action which can be controlled under opendistro security plugin. Define default roles for LTR plugin. Add some roles infos in each document, like model, feature set etc. to provide document level permission control.

What do you think? If need more details, I can provide it.

Best regards,
Jing

[nathancday]

Thanks for continuing to support this project. We are going to have a brief discussion about this today and will respond here with any questions. I think Ani wanted to set up a proper meeting to discuss this next week and I'm still figuring out who should be there from OSC. My goal is to keep this issue up to date with the various discussions so we have single record of where we are on it.

[jngz-es]

Some steps,

1. Append user info to each document.
   a. Add a cluster setting for enable/disable appending user info.
   b. Set index.default_pipeline for each LTR index. The default pipeline which could be created by the other plugin or LTR attaches user info when ingesting documents.

2. REST APIs permission control (optional).
   Associate a transport action with each API if not present, so user can define roles on cluster privileges to control access of APIs.
   An example pr, Adding RestActions support Delete Detector API opendistro-for-elasticsearch/anomaly-detection#238.
   Open Distro Security permission control, https://opendistro.github.io/for-elasticsearch-docs/docs/security/access-control/permissions/.

3. Prevent users from access LTR indices directly (optional).
   Currently this feature is only supported by Open Distro Security Plugin, no changes is needed by LTR plugin.

Based on the above, user can

1. enable/disable user info appending.
2. define roles with document level security by indicating user info filtering according to using elastic/opendistro security plugin. (don't support write APIs)
3. define roles with REST APIs security by indicating cluster permission. (optional)
4. not access LTR indices directly only with opendistro security plugin. (optional)

[nathancday]

Wanted to share some of my thoughts about the step you outlined above for general discussion.

I'd like to gauge community desire for these security functions. I haven't heard of people wanting this level of control over LTR index access, but that doesn't mean that need isn't out there.

Separately form the first bit, this plugin is used by Elasticsearch and OpenDistro users today. We want to keep this balance and make sure contributions can benefit both communities. For the abilities you suggest, I'd like to discuss where those abilities would be helping.

Using a rubric like this:

	ES benefit	OD benefit	Effort size
1
2
3
4

I also want to keep in mind how much code would need to be changed to gain these new abilities, that's what the Effort Size column is about. Small/Medium/Large breakdowns are good enough for now. For example a minor change like adding a new "user tag" field to the indexes would be a small, but incorporating rest roles via the cluster security would be probably be large.