Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Cluster settings with restricted update permissions #4360

Open
expani opened this issue May 20, 2024 · 4 comments
Open

[Feature Request] Cluster settings with restricted update permissions #4360

expani opened this issue May 20, 2024 · 4 comments
Labels
enhancement New feature or request triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable.

Comments

@expani
Copy link

expani commented May 20, 2024

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

@expani expani added enhancement New feature or request untriaged Require the attention of the repository maintainers and may need to be prioritized labels May 20, 2024
@krishna-ggk
Copy link
Contributor

krishna-ggk commented May 20, 2024

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
Copy link
Author

expani commented May 20, 2024

@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
Copy link
Member

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

@peternied peternied transferred this issue from opensearch-project/OpenSearch May 22, 2024
@stephen-crawford
Copy link
Contributor

[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.

@stephen-crawford stephen-crawford added triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable. and removed untriaged Require the attention of the repository maintainers and may need to be prioritized labels Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triaged Issues labeled as 'Triaged' have been reviewed and are deemed actionable.
Projects
None yet
Development

No branches or pull requests

4 participants