Is your feature request related to a problem?

RoleBasedActionPrivileges is a precomputed, optimized privilege structure derived from role and action group configuration. The class documentation explicitly says its lifecycle corresponds to the lifecycle of the role and action group configuration, and that a new instance needs to be built when role or action group configuration changes. It also notes that stateful index privilege updates on large clusters can take on the order of ~1000 ms. ([raw.githubusercontent.com]1)

However, it appears that RoleBasedActionPrivileges may currently be reconstructed for broader security configuration changes than necessary, including updates to config types that do not change the role/action-group-derived privilege model itself.

Examples of config changes that should not require rebuilding RoleBasedActionPrivileges include:

• internalusers
• rolesmapping
• other unrelated security config documents

From a dependency perspective, this structure should only need to be rebuilt when the inputs it is derived from change:

• roles
• actiongroups

The Security plugin APIs and configuration model treat users, roles, role mappings, and action groups as separate config domains, which suggests these changes can be invalidated more selectively. ([OpenSearch Docs]2)

What solution would you like?

Tighten the invalidation / rebuild logic so that RoleBasedActionPrivileges is reconstructed only when:

• role definitions change, or
• action group definitions change.

Changes to unrelated security config types should not trigger reconstruction.

For example:

• changing an internal user password should not rebuild RoleBasedActionPrivileges
• changing backend role mappings for a user should not rebuild RoleBasedActionPrivileges
• changing unrelated security plugin settings/documents should not rebuild RoleBasedActionPrivileges

Those changes may require refreshing other security state, but not this particular precomputed privilege structure.

Why this helps

Rebuilding RoleBasedActionPrivileges is more expensive than necessary if it is triggered by config changes that do not affect its actual inputs. Since the class is specifically derived from roles and actionGroups, broader rebuild triggers create avoidable CPU work, object churn, and latency spikes during security config updates. ([GitHub]1)

This is especially relevant in clusters where:

• security configs are updated frequently,
• user and role mapping data changes more often than role definitions,
• and role/action-group structures are large enough that reconstruction is noticeable.

Additional context

RoleBasedActionPrivileges is already designed as a long-lived precomputed structure whose lifecycle matches role/action-group configuration, so narrowing reconstruction triggers would be consistent with the class’ stated design intent. ([GitHub]1)