[Feature/Extensions] Implement PrivilegeEvaluator on REST Layer.

[DarshitChanpura]

As part of the new REST API authorization flow, a new PrivilegesEvaluator is required to evaluate a user against request REST route.
This involves:

• [Feature/Extensions] Supporting cluster_permissions nomenclature #2752
  - [ ] Supporting index permissions nomenclature Not needed as these will always be evaluated as cluster permissions at REST level.
  - [ ] Supporting index patterns

[cwperks]

[Triage] @willyborankin Tagging you on this issue

[cwperks]

@willyborankin I have a 3 PRs open across Security, core and the SDK to add a notion of a ProtectedRoute which is a named route. The PRs are still open so I'm not sure if the SDK team or core was comfortable with the approach, but it was trying to solve the problem of naming a REST action similar to a transport action to have a name to place in a role definition. Similar to the work you had done around the security APIs. opensearch-project/OpenSearch#6870

[willyborankin]

I think to add such functionality (it doesn't matter how permissions will look like) no need to add yet another PrivilegesEvaluator. The main thing in this case just avoid of using

  cluster_permissions:
    - "*"

for that I added method:

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

Line 42 in 15860b6

boolean hasExplicitClusterPermissionPermission(String action);

so together with this method to add permissions check for REST calls you need at least 5 lines of code. @cwperks, @DarshitChanpura wdyt?

[cwperks]

@willyborankin I think it may be necessary to add at least a separate PrivielegesEvaluator.evaluate method because the inputs to the method would be different on the REST-Layer opposed to the Transport-Layer.

On the Transport-Layer the existing PrivelegesEvaluator takes the input:

public PrivilegesEvaluatorResponse evaluate(final User user, String action0, final ActionRequest request, Task task, final Set<String> injectedRoles)

but the Task and ActionRequest would not be available on the REST-Layer. This PR introduces the concept of RestLayerPrivilegesEvaluator which uses a different method signature for evaluation.

public PrivilegesEvaluatorResponse evaluate(final User user, String action0)

It would be great to have a single place for evaluating privileges, but I'm not entirely sure if its possible yet because the ActionRequest is a type of TransportRequest.

The PR linked above works for evaluating privileges on routes mapped to a single name (like a cluster_permission), but does not address how plugins that define index_permissions would migrate to an extension. Since REST Request forwarding to an extension occurs in the REST-Layer the request needs to be blocked before its forwarded inside of SecurityRestFilter.wrap.

One of the goals with extensions is that all existing optional plugins (apart from security and job-scheduler) could be re-written as an extension and use the SDK. That would include supporting ISM and CCR which define index permissions:

index_management_full_access:
  reserved: true
  cluster_permissions:
    - "cluster:admin/opendistro/ism/*"
    - "cluster:admin/opendistro/rollup/*"
    - "cluster:admin/opendistro/transform/*"
    - "cluster:admin/opensearch/notifications/feature/publish"
  index_permissions:
    - index_patterns:
        - '*'
      allowed_actions:
        - 'indices:admin/opensearch/ism/*'

# Allows users to use all cross cluster replication functionality at leader cluster
cross_cluster_replication_leader_full_access:
  reserved: true
  index_permissions:
    - index_patterns:
        - '*'
      allowed_actions:
        - "indices:admin/plugins/replication/index/setup/validate"
        - "indices:data/read/plugins/replication/changes"
        - "indices:data/read/plugins/replication/file_chunk"

[DarshitChanpura]

@cwperks @willyborankin The current implementation of NamedRoute allows declaring a unique name for a route and has option to test against cluster permissions. For plugins looking to transform to extensions, we have an option to add cluster_permissions as a set of legacy action names on the route. However, for index_permissions I think we have an option to not support as them in REST layer authz, since we are not removing Transport Layer authz (index-permissions are still going to be evaluated at Transport-layer for DLS/FLS and other index related checks). Please let me know if I'm misunderstanding something.

[DarshitChanpura]

Closing this issue. Please feel free to open it if you think it needs more comments.

[peternied]

@DarshitChanpura Can we close those 'unchecked' items in the description before we close this issue?

[DarshitChanpura]

Done.