[RFC] Should static key be part of keys allowed to an admin when interaction with action groups via API.

[DarshitChanpura]

Coming from this discussion thread on the PR: #4371.

At the moment, we do not have clear answer neither there is a clear distinction between usages of hidden, reserved and static.

Expected outcome

• An answer has been provided on whether static field should be allowed to be updated for an admin user.

[willyborankin]

Not only action groups but roles, roles mapping,internal users and tenants

[stephen-crawford]

[Triage] Thanks for filing this issue @DarshitChanpura. Swapped to RFC in the title just so more people click and provide their thoughts. I will look into the links you shared and try to offer an opinion later today.

[nibix]

I just saw this by coincidence, so I thought I'll give you my five cents.

As far as I understand it, the meaning of static, reserved and hidden in the config files is as follows:

• static: Config entries which are defined in the source code (in https://github.com/opensearch-project/security/tree/main/src/main/resources/static_config ) are marked as such. These are config entries on which you can rely to be everywhere - like the action groups read or crud (except when disabled by a weird config option). Static config entries should not be exposed or editable by the REST APIs or the securityadmin tool. Having this as an attribute in the YAML file feels totally redundant, though, as static entries can be identified as such by being present in the respective collection here:

security/src/main/java/org/opensearch/security/securityconf/DynamicConfigFactory.java

Line 81 in 2b5a811

private static SecurityDynamicConfiguration<RoleV7> staticRoles = SecurityDynamicConfiguration.empty();

• reserved: This is a config entry which can be only modified as a super admin user. It is visible to normal users, though.

• hidden: This is a config entry which can be only modifed and seen by a super admin user.

So, to come back to the question:

Should static key be part of keys allowed to an admin when interaction with action groups via API.

My IMHO would be "no" :-)

[DarshitChanpura]

@willyborankin based on @nibix 's explanation of the keywords and opinion, it seems like _static should not be part of admin actions via REST API.

[willyborankin]

@DarshitChanpura Agree. Lets convert it to an issue and remove it. Only one thing: Since the functionality is in the public documentation it should be implemented for 3.x version only. Wdyt?

[DarshitChanpura]

Agreed as I'm not aware of the blast radius of this so 3.x sounds like a safer route to implement this.