Permissions issue for the resolve_index api

[shivindera]

Elasticsearch Version

latest

Installed Plugins

No response

Java Version

18.0.1.1

OS Version

Linux 5.17.6-1-MANJARO

Problem Description

We created a hasData service which utilizes the resolve_index api to check whether ES data exists. When making a call to internal/index-pattern-management/resolve_index to query whether data exists or not, in certain scenarios it fails with a 500 Internal Server Error.

The ES error being -

security_exception: [security_exception] Reason: action [indices:admin/resolve/index] is unauthorized for user [test_user] with roles [test_dashboard_user,reporting_user], this
action is granted by the index privileges [view_index_metadata,manage,all]

The scenarios being:
Scenario one:

1. There are 3 indices
2. User has read access to 1 of the indices, but not to the other two
3. The call fails with a 500 Internal Server Error. The user should be able to see the index they have access to.

Scenario two:

1. This refers to a scenario where the user has read access to the index, but no view_index_metadata privileges.

Original issue ticket in Kibana for reference - #132478

Steps to Reproduce

The user has read access to the index, but no view_index_metadata privileges.
The api fails with a 500 due to the missing permissions.

Logs (if relevant)

security_exception: [security_exception] Reason: action [indices:admin/resolve/index] is unauthorized for user [test_user] with roles [test_dashboard_user,reporting_user], this
action is granted by the index privileges [view_index_metadata,manage,all]

[elasticmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[shivindera]

This is already discussed this with the es-security team and they had agreed to add the action to the read privilege as well.

[shivindera]

CC'ing: @tvernum @dakrone @javanna @stacey-gammon @mattkime @ywangd @jakelandis

[ywangd]

The call fails with a 500 Internal Server Error. The user should be able to see the index they have access to.

Are you sure it is a 500 error? It should be 403. A 500 error for this failure seems to be a bug on its own.

[javanna]

based on previous discussion, it's the api at the ui level that returns a 500, ES returns 403.