[Feature Request] Cluster settings with restricted update permissions

[expani]

Is your feature request related to a problem? Please describe

OpenSearch allows any user who has the permission cluster:admin/settings/update to update any dynamic cluster setting.

Updating some cluster settings like shard allocation speed control knobs indices.recovery.max_bytes_per_sec are required by operators to maintain their clusters, but this also gives them a blanket permission to update all other settings.

I was planning to introduce a new setting which can only be controlled by admins to enable/disable a Core feature for all users in the cluster. But, the above limitation will also give regular operators of the clusters the same privileges.

Describe the solution you'd like

I am proposing a new Cluster Setting Property named RestrictedUpdate which developers can define when creating a new cluster setting or modify an existing one.

    public static final Setting<Boolean> IS_FEATURE_ENABLED = Setting.boolSetting(
        "feature_enabled",
        false,
        Property.Dynamic,
        Property.NodeScope,
        Property.RestrictedUpdate
    );

If this property is associated with a cluster setting, then updating them will require a new permission cluster:admin/settings/update/restricted

This will allow the admins of the cluster to let operators manage the existing cluster settings for maintaining the cluster while restricting them on updating certain cluster settings.

Looking forward for feedback on whether having this new property makes sense OR all such changes must be made based on the alternative solution described.

Related component

Other

Describe alternatives you've considered

An alternative in such cases is to go down the path of creating our own system index and maintaining the settings within them by exposing APIs.

This would be similar to how Security Config is implemented today.

Although, this approach makes sense for complex settings like Security,Alerting; etc but seems overkill for a single boolean setting to control the enablement of a feature.

Additional context

No response

[krishna-ggk]

Restricted setting requiring more control can be super helpful as you suggested and most plugins are implementing custom access control by persisting config in system index.

One aspect I'm struggling a bit is that the Restricted setting is only applicable with security plugin deployed. Is there any further meaningful context we can associate which could also apply for non-security plugin deployments of OpenSearch?

[expani]

@krishna-ggk AFAIK if a cluster doesn't have security plugin enabled, then all users can perform all actions. Associating context with the request and evaluating permissions based on it will turn out the same as implementing security plugin.

IMO If an admin decides to not enable security plugin, then they are making a choice of disabling any fine grained access control features as well.

There are some open initiatives which add Security by default and will let Admins make a more conscious decision when disabling it.

[peternied]

[Triage - attendees 1 2 3 4 5 6 7 8 9 10]
@expani Thanks for creating this issue, transferring to the security plugin repo

[stephen-crawford]

[Triage] Hi @expani thank you for filing this issue. This seems like a great idea. Please feel free to open a PR for review in the Security repo.