[FEATURE] Permissions lists CLUSTER_PERMISSIONS/INDEX_PERMISSIONS should be retrieved at runtime from plugins

[peternied]

Is your feature request related to a problem?
Developers in the OpenSearch project have to update a file outside their repository to update the list of permissions that are shown in the security plugin's permission UX.

This makes testing updates difficult and requires coordination with an external team. Since changes of this nature arrive toward the end of the release lifecycle it causes delays that can jeopardize the associated features.

What solution would you like?
It would be way easier if the list of permissions could be supplied at runtime by plugins and the security dashboard plugin could read, merge, sort, and present those values in the UX.

Do you have any additional context?
Reducing the amount of overhead to get common changes done in OpenSearch would benefit all plugins - additional plugins that aren't part of the OpenSearch distribution would have a mechanism to supply their own permissions to include in the list.

This discussion in a recent PR [1] required back and forth along with realigning expectations - and ultimately everything was already working as intended.

• [1] configure new ML plugin actions #1182

[peternied]

@ylwu-amzn What do you think of this proposal?

[ylwu-amzn]

Please prepare a RFC with high level design and discuss with all plugin teams and community.

[peternied]

Unfortunately I do not have bandwidth for this feature and I wanted to capture its essence before it slipped my mind. This issue will be discussed during our open triage meetings [1] if you'd like to attend

[1] https://www.meetup.com/opensearch/events/bbrkzsydcpbkb/

[peternied]

@dagneyb This sounds like its related to registration points and other extensibility features - is there an overall effort this should be attached to?

[peternied]

Another time when this feature would have prevented a bad user experience

• Add Notifications cluster permissions #1290

[cwperks]

X-Posting from this comment thread: #1725 (comment)

It is possible to get a full list of transport actions that have been registered in core (native actions + actions registered by plugins/modules), but there are a couple of problems:

• The actions aren't necessarily categorized the same way that the security plugin categorizes the actions. i.e. This new action is a cluster permission even though it begins with indices:. At some point, I think these need to be revisited to ensure that the action naming is consistent and works with the security plugin.
• Not all transport actions are meant to be run by users, some may be internal and only invoked by a process. I think the security plugin's ConfigUpdateAction is one example of that.