Restrict access to Opensearch-Dashboards Advanced settings

[aggarwalShivani]

Is your feature request related to a problem? Please describe.
Currently there is no way to restrict users from modifying the Advanced Settings from Opensearch Dashboards UI.
Issue described in discussion forum - https://forum.opensearch.org/t/restrict-access-to-opensearch-dashboards-advanced-settings/11524

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Currently with security plugin enabled, if a user has write access to .kibana_1 index, they would be able to create/modify Saved Objects (visualizations etc) and also modify the Advanced Settings. It is not possible to further granularize the permissions and restrict access to Advanced Settings alone - such that user could create Saved objects but not modify Advanced Settings.

Describe the solution you'd like
A simple way to hide/disable the “Advanced Settings” edit option on the UI or restrict access to it for specific users?
If there's an additional permission needed to edit Advanced Settings, and if user does not have that permission, it shouldn't allow edits.

Describe alternatives you've considered
In elastic’s x-pack distribution, such a provision exists. Refer here.

[kavilla]

Hello @aggarwalShivani,

Thanks for opening. I like this, let's re-route to security plugin for now to see if there is this functionality. If not we can talk about next steps.

[DarshitChanpura]

[Triage] Thank you for filing this issue. Seems like a good improvement and we would be happy to accept a PR for this.

@shanilpa Can you please provide more inputs from UX/UI side of things?

[shanilpa]

Thanks for filing this issue @aggarwalShivani! I have a couple of clarifying questions that will help us address your specific pain points but also allow us to build a robust solution for other potential use cases.

Clarifying questions

1. It sounds like you need to restrict access to all of advanced settings for specific users. Is this correct?
2. Do you still require users to view the settings in advanced settings - they just can't make edits?
3. I can anticipate a use case where someone might want to allow some users access to advanced settings but not access to all options and fields within there. Is this more granular control something you'd find useful? If so what fields would you like to be accessible and which would you like to be restricted?

[tibz7]

Hello,
Was there already some progress regarding this feature? I did not find any permissions that helps hidding advanced settings from "non admin" users. Also it would be good to have permissions per UI feature, and if the user does not have the necessery permission the feautre is unavailable to him.

[tjbaker]

Personally, I would like to be able to prohibit PUT/POST/PATCH on the api that updates the global settings via fine grained access controls. I would like to disable modification to those global settings and only allow a specific role to write.

The problem we are facing is that people keep changing the timezone setting to be their preference, when the company standard is to leave it at UTC. Nearly once a week a user changes the setting, not realizing that it is a global setting and then someone needs to change it back.

[davidlago]

Tagging @wbeckler as he is working on workspaces, the replacement for tenants. If I understand correctly, Advanced Settings are not global, they are tenant-specific. Someone with write access to the tenant can also modify the tenant settings. The people who can mess up the timezone can also edit visualizations and mess up with those too.

I think that the question here is probably better framed as: could some of these settings be made user-specific and not global to the tenant? I'd venture to say that the better user experience here is to let them select their timezone, not to prevent them from changing it at all.

[jgough]

When you view Advanced Settings it comes with a very big warning:

Caution: You can break stuff here

Be careful in here, these settings are for very advanced users only. Tweaks you make here can break large portions of OpenSearch Dashboards.

It would be better in my opinion to be able to block users from being able to "break large portions of OpenSearch Dashboards" for all users rather than hoping that they won't.

[davidlago]

It would be better in my opinion to be able to block users from being able to "break large portions of OpenSearch Dashboards" for all users rather than hoping that they won't.

Those users can delete all dashboards... we would still be hoping that they won't.

[davidlago]

Look what I found #277

[jgough]

Those users can delete all dashboards... we would still be hoping that they won't.

I think that unfamiliarity with advanced settings poses a greater threat of accidental damage than misunderstanding the 'Delete' button.

Incompetence vs Malice

Security shouldn't only guard against the latter!

[davidlago]

Yeah, I think that banner warning that "you can break stuff" is the (not very successful) attempt at guarding against the former.

[davidlago]

I know @shanilpa has given a lot of thought about breaking down context (i.e. are you modifying things just for you, for the whole tenant, for the whole application) and making it very explicit which one you're in. If the user was absolutely certain that changing that timezone was going to affect everyone it would no longer be incompetence... but they would still not be able to accomplish what they want: to set their timezone to something that makes sense to them.

@shanilpa @wbeckler and others... wondering if there are other RFCs/work being done around this breaking down and making context explicit?

[davidlago]

Found it! opensearch-project/OpenSearch-Dashboards#4298 (see "Organizing your work" section):

System settings: We want to enable dashboards admins to configure system defaults, and dashboard level defaults. This means an audit of “Advanced settings” to determine which of those settings should be controlled at an application level, which of those controls could be moved to workspace settings, and which of those belong in user settings. For example, Theme and Dark-mode selection should allow for an admin to set an application default, and for a user to override it just for themselves. Today, if you change a theme, it changes the interface for all users.

There is associated work happening on the access control area for these saved objects here. I'm closing this one in favor of those efforts and will be linking this discussion there for context.