Implement resource permission evaluation in security

[stephen-crawford]

Description

[Describe what this change achieves]
This change adds resource permission evaluation into the Security plugin framework. This is accomplished by adding a new class ResourcePrivilegesEvaluator and expanding the RoleV7 definition to account for the new Resource class.

This PR is dependent on the related change in core: opensearch-project/OpenSearch#15230

Issues Resolved

#4562

Testing

[Please provide details of testing done: unit testing, integration testing and manual testing]

Check List

• New functionality includes testing
• New functionality has been documented
• New Roles/Permissions have a corresponding security dashboards plugin PR
• API changes companion pull request created
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[peternied]

Good first steps, thanks for putting this out there.

[peternied]

• This is a first in this class, is this a version of [FEATURE] Security plugin config entries should have a created_at and updated_at timestamp #3079 that you wanted to include for the new type?

[stephen-crawford]

To be honest, I just thought it seemed like it may be a nice thing to have since we were adding the new class. I can also remove it though and don't feel strongly about its inclusion.

[cwperks]

FYI I have been exploring the idea I posted about here on my fork here.

Ultimately, I think the resource owner needs to be empowered to determine how they want to share the resource with others without going through the admin of the cluster.

In order for ml-commons to adopt the new scheme that security will provide, how will the public, private and restricted attributes translate to this new scheme?

[stephen-crawford]

HI @cwperks, thanks for your thoughtful comments.

I tried to address your thoughts below.

Ultimately, I think the resource owner needs to be empowered to determine how they want to share the resource with others without going through the admin of the cluster.

I think most patterns we follow force users to rely on the cluster operator/administrator in some ways. I understand you would like to model resources as registered fields in a per-resource indices which any user can create. This is quite different than how roles work and seems better suited outside of the roles system. Perhaps, you discussed things elsewhere, but based off #4500 (comment) it seemed like this discussion was being tabled.

In order for ml-commons to adopt the new scheme that security will provide, how will the public, private and restricted attributes translate to this new scheme?

I would expect the ML-commons plugin to override ActionRequests for their plugin and add the associated resources to the new method being added (in core):

/**
     * Should be overwritten by implementing plugins with the resources each actionRequest requires.
     * Bypasses resource evaluation by default.
     */
    public List<String> getResources() {
        return Collections.emptyList();
    }

From there, I would expect there to be a role i.e. ml-all-access which included the Resource with a pattern 'ml-commons:*' or whatever the resources were called. Similarly, they would need to define roles which had the appropriate analog for private and restricted as shown in the documentation. The assignment of the appropriate roles would have to be carried out by an administrator.

---

@DarshitChanpura @cwperks It seems like there is still decisions to be made around the design of the feature. I would describe DC's intention as more of "adding resource controls to role based access controls" while Craig seems to be more interested in adding an independent access system for resources. I suggest we reach consensus on this before moving forward.

It is probably best to carry this on over at #4500