Improve the security permission check in cat indices (_cat/indices) API

[bowenlan-amzn]

Is your feature request related to a problem? Please describe.

Today, to be able to call _cat/indices successfully, you need to have a permission at least with these permissions:

    "cluster_permissions" : [
      "cluster:monitor/state",
      "cluster:monitor/health"
    ],
    "index_permissions" : [
      {
        "index_patterns" : [
          "*"
        ],
        "allowed_actions" : [
          "indices:monitor/settings/get",
          "indices:monitor/stats"
        ]
      }
    ]

If the index_patterns is not set to "*" but "log-*", _cat/indices fails with a security exception:
"no permissions for [indices:monitor/settings/get] and User [name=bowen, backend_roles=[], requestedTenant=__user__]
I suppose this is because cluster has other indices that don't match "log-*" and security check fails.
You will be able to call _cat/indices/log-* successfully though.

Describe the solution you'd like
Instead of failing the full request, can we improve the user experience of _cat/indices to return the indices user has permission of?
To be specific, if user has index permission on "log-*", calling _cat/indices can return the indices start with log- in the cluster.

[anasalkouz]

@davidlago do you see any security concern of doing this change?

@nandi-github Do you thing it's the right thing from customer perspective to list indices that who access to read, which won't give him any visibility if there are other indices on the cluster.

[davidlago]

I guess we could leverage the existing do_not_fail_on_forbidden config flag that is used in the Privileges Evaluator and add the indices:monitor permissions to the considered patterns here.

Is there anything else that is not index-specific that would be revealing things we shouldn't to a user who can only see a subset of indexes making these calls? (tagging @peternied for an additional set of eyes)

[peternied]

Thanks for writing this up, that is a much better user experience.

From a user experience/information disclosure, the scenario is in-line with our existing DNDOF cases. The filtering logic implemented in the IndexResolverReplacer [1] would need to be updated to handle GetSettingsRequest that supports this scenario.

I'll transfer this to the security repository to be triaged by the team and where the change would need to be made. This would be a great first issue for anyone if they are looking to get involved in the security codebase.

[1]

security/src/main/java/org/opensearch/security/resolver/IndexResolverReplacer.java

Line 536 in 93fe633

private boolean getOrReplaceAllIndices(final Object request, final IndicesProvider provider, boolean allowEmptyIndices) {

[davidlago]

Closing in favor of #1815 to track in a single place