[FEATURE] Add `kibana_admin` level for `tenant_permissions` to allow advanced settings modification in tenant

[cwperks]

Is your feature request related to a problem?

Currently, OpenSearch only has 2 levels of access for a tenant:

• kibana_all_read - read only access to a tenant
• kibana_all_write - read and write access to a tenant

Given that advanced settings is a separate document in the .kibana index, any user with kibana_read_write can make modifications since its a write operation to a doc in a .kibana index.

OpenSearch should distinguish between 2 separate levels of write users:

• kibana_all_write - users that have permissions to create new visualizations and dashboards and can change settings
• kibana_only_write - users that have permissions to create new visualizations and dashboards but cannot change settings

What solution would you like?

To achieve this, I propose creating a separate API in the opensearch-dashboards module of core. This API will be a wrapper around the index operation to the .kibana index and allows the security plugin to authorize at the API level instead of just authorizing the index operation to the .kibana index.

What alternatives have you considered?

Status Quo

Do you have any additional context?
Add any other context or screenshots about the feature request here.

[cwperks]

So I took a look at this as a means to start using the opensearch-dashboards module of core which is currently unused.

I'm primarily interested in looking at this, because I'd like to start using that module for all saved objects requests which are currently done as direct index requests.

The Proof of Concept is in these 3 PRs:

• [OpenSearch Dashboards] Create API for getting and updating advanced settings in favor of direct .kibana index operation cwperks/OpenSearch#338
• Use dedicated advanced settings API cwperks/OpenSearch-Dashboards#3
• WIP on Creating Kibana admin level that's different then write and allows settings to be updated cwperks/security#75

I'm trying to decide if I should push this forward because I think using the opensearch-dashboards module to a greater extent will warrant a larger discussion but by going through the exercise of figuring out what it would take to implement a solution to this problem I learned a lot of existing logic in the security repo that replaces the dashboards index on requests that are targeted for the .kibana index. This is another such usage of the IndicesRequest.Replaceable interface.

Curious to solicit thoughts from people on whether this should move forward. @DarshitChanpura @shikharj05 @nibix. Thoughts on using this as a means to start using the opensearch-dashboards module of core more?