[RFC] Remove the `opensearch-dashboards` module from this repo

[cwperks]

Please describe the end goal of this project

There is a module in core called opensearch-dashboards that appears to be unused.

This plugin is a single file and all it does is register a few RestHandlers that wrap common operations around indices. On the surface, it looks like the purpose of this plugin is to facilitate requests from OpenSearch-Dashboards to allow dashboards to write to the saved objects (.kibana or .opensearch_dashboards*) index, but its not actually used by dashboards.

When running a cluster with security, dashboards must be configured with opensearch.username and opensearch.password which is used to write and read from the saved objects index or indices if using multi-tenancy. In the demo configuration, this is the kibanaserver user which is mapped to the kibana_server role which grants it permission on those indices.

This is the list of RestHandlers that it registers and it prefixes all of their existing routes with _opensearch_dashboards/

i.e. The create index API that this plugins registers is PUT /_opensearch_dashboards/{idx} instead of PUT/{idx}

Judging by the wrapper in this class it looks like the plugin is trying to provide additional protections to the saved objects indices.

If the module is unused then is there any purpose in keeping the code in core?

Supporting References

Related to work in https://github.com/opensearch-project/security/issues/4439 that is analyzing system indices across all default modules and plugins

Issues

Related to https://github.com/opensearch-project/security/issues/4439

Related component

Plugins

[peternied]

[Triage - attendees 1 2 3] @cwperks Thanks for creating this issue, I've updated the title to reflect that we'd like comments on this issue before making a decision

[andrross]

@reta Do you know the purpose of this module?

A simple search for the _opensearch_dashboards prefix picks up a bunch of false positives, but digging through the results I haven't found anything that appears to actually use that prefix.

[reta]

@reta Do you know the purpose of this module?

I actually don't to be fair, but it says 'Plugin exposing APIs for OpenSearch Dashboards system indices'

[dblock]

This might be of interest for the list of the APIs, https://github.com/opensearch-project/opensearch-api-specification/issues/236.

[nibix]

My five cents:

I am pretty sure that the purpose of this plugin is to mark the internal indices known as .kibana, .kibana_* or believed to be known as .opensearch_dashboards, etc. as system indices, i.e., to restrict access to these.

Before the fork, there were unfinished efforts to enhance system index protection. One intermediate goal was to allow system index access only if the client (in this case the internal Dashboards server), would (insecurely, just by a REST header) identify as a certain product.

I have not checked it, but I actually believe that this intermediate goal is alread reached when for fork occurred. However, this module is inoperable due to the mismatch between the believed index name and the one that is still being used.

[cwperks]

@nibix that's correct and looks like the work is incompleted as dashboards does direct index access today.

FYI I've been thinking about this more and I think that Resource Sharing and Access Control that security is introducing will ultimately provide a path here for using this plugin. A couple of problems to tackle with regards to OSD:

1. Make .kibana* (or .opensearch_dashboards*) system indices - These indices today are not formally system indices and requests against these may be authorized as normal indices.
2. Introduce finer grained access controls - i.e. introduce notion of ownership to Saved Objects like dashboards and visualizations. The creator of a dashboards can then specify sharing with other users in the system.
   • Today the access control is done at the tenant level. A user either has write access to the tenant (write access to all saved objects) or read access which prevents them from making any changes.

With Resource Sharing and Access Control, an assumption is made that a Sharable Resource is simply a doc with metadata stored in a system index and the .kibana indices would qualify.