[FEATURE] Automatically upgrade default security configs (static + reserved) on cluster upgrade

[cwperks]

Is your feature request related to a problem?

In Opensearch 2.14, 2 new APIs were introduced that allowed cluster administrators determine if their default security configs were outdated and take action accordingly. Those APIs are:

1. Configuration Upgrade Check: https://opensearch.org/docs/latest/security/access-control/api/#configuration-upgrade-check
2. Configuration Upgrade: https://opensearch.org/docs/latest/security/access-control/api/#configuration-upgrade

Below are definitions for "default" and "security config":

Default: Default means that either static or reserved is set to true
Security Config: This means the various different security config types. i.e. roles and action groups

These APIs require intervention, whereas it should also be possible to specify whether a cluster should perform these upgrades automatically.

What solution would you like?

Introduce a new feature flag with default set to true. (Maybe plugins.security.automatically_upgrade_default_security_configurations?) that will check if the default security configs are outdated on node bootstrap and, if outdated, perform the upgrade automatically.

What alternatives have you considered?

Status quo

[cwperks]

This is the Rest API handler for config upgrades.

First though is to check if the default configs are outdated here. If outdated, perform the upgrade.

[nibix]

The static action group definition could be leveraged to solve this problem without having to rewrite the data persisted in the index:

https://github.com/opensearch-project/security/blob/main/src/main/resources/static_config/static_action_groups.yml

This way one would add action group names to the roles configuration instead of the actual action names (like "indices:data/write/bulk"). These action groups can be considered as a abstraction from implementation details (action names) to a user oriented interface (action group names).

Thus, whenever a new action is introduced, the action name just needs to be added to the respective static action group.

Note: It's important to keep in mind that static action groups are not persisted to the config index. Thus, the addition of entries to static action groups does not require modification of persisted data.