Handle the indices pattern `["", "-"]` when grouping indices by cluster name #128610

pawankartik-elastic · 2025-05-29T08:48:40Z

The authorisation code uses the pattern ["*", "-*"] whose semantics mean that it's alright to return an empty response. However, we don't seem to handle this scenario in most (if not all) endpoints and especially in groupIndices(). When such a pattern is not handled, groupIndices() associates both the indices with the local cluster and we unknowingly end up including the local cluster in the response. This is why the _resolve/cluster endpoint will include the local cluster in the response when you specify a pattern that does not match any remote. E.g.: _resolve/cluster/my_nonexistent_*:w*.

When you have security turned on and run an ES|QL query where the remote pattern does not match any clusters, you're fine and do not get back results from the local cluster (unsecured model was prone to this bug which mpeterson fixed in October last year). However, _resolve/cluster is affected under the same security model. There's discrepancy here: sometimes we fallback to the local cluster and sometimes we don't. IMO, ideally, we shouldn't and this is problematic.

There could be other endpoints that maybe affected in a similar way. The best way forward I see is to handle it in a place that's most likely to trip. Otherwise, we'll have to run a precheck everywhere to detect such a pattern before we call APIs like groupIndices(). This is cumbersome and we could easily forget to do so.

…ster name

smalyshev · 2025-05-29T17:14:20Z

LGTM

smalyshev · 2025-05-29T17:17:51Z

Should probably mention #115872, though it looks like it's different code path - this one with security, and #115872 is without security.

pawankartik-elastic · 2025-05-29T19:00:49Z

Yes, I'll mention the issue and yes, this is a different codepath. We need to handle this index pattern only when the security is turned on (as of now; I don't think we're using it elsewhere AFAIK).

pawankartik-elastic · 2025-05-29T19:16:28Z

I've given it another thought: the issue you mentioned specifically talks about the unsecured model. Here, the issue is due to the pattern that's being injected by the auth-related code and to me, that seems like a different, yet tangential issue.

server/src/main/java/org/elasticsearch/transport/RemoteClusterService.java

elasticsearchmachine · 2025-06-02T11:06:19Z

Pinging @elastic/es-search-foundations (Team:Search Foundations)

elasticsearchmachine · 2025-06-02T11:06:20Z

Hi @pawankartik-elastic, I've created a changelog YAML for you.

javanna

left a comment about possible longer term changes, LGTM

javanna · 2025-06-02T19:04:35Z

server/src/main/java/org/elasticsearch/transport/RemoteClusterService.java

 final Map<String, OriginalIndices> originalIndicesMap = new HashMap<>();
- final Map<String, List<String>> groupedIndices = groupClusterIndices(remoteClusterNames, indices);
+ final Map<String, List<String>> groupedIndices;
+ if (returnLocalAll == false && IndexNameExpressionResolver.isNoneExpression(indices)) {


perhaps add a comment here, that explains the semantics of returnLocalAll and where it's used set to false.

I wonder if in the longer run, we should consider making resolve cluster go through a specific method that resolves clusters instead of indices, and remove this flag that makes things a little difficult to read. What do you think? Do we ever consume the indices names (values in the map) or only the cluster aliases (keys in the map)?

Although we don't return the indices names directly, the _resolve/cluster call's response has a key matching_indices that tells if the specified cluster has the specified index.

elasticsearchmachine · 2025-06-03T12:53:36Z

💔 Backport failed

Status	Branch	Result
✅	8.19
❌	9.0	Commit could not be cherrypicked due to conflicts
❌	8.18	Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 128610

…ster name (elastic#128610) The auth code injects the pattern `["*", "-*"]` to specify that it's okay to return an empty response because user's patterns did not match any remote clusters. However, we fail to recognise this specific pattern and `groupIndices()` eventually associates it with the local cluster. This causes Elasticsearch to fallback to the local cluster unknowingly and return its details back to the user even though the user hasn't requested any info about the local cluster.

…ster name (#128610) (#128822) The auth code injects the pattern `["*", "-*"]` to specify that it's okay to return an empty response because user's patterns did not match any remote clusters. However, we fail to recognise this specific pattern and `groupIndices()` eventually associates it with the local cluster. This causes Elasticsearch to fallback to the local cluster unknowingly and return its details back to the user even though the user hasn't requested any info about the local cluster.

…ster name (elastic#128610) The auth code injects the pattern `["*", "-*"]` to specify that it's okay to return an empty response because user's patterns did not match any remote clusters. However, we fail to recognise this specific pattern and `groupIndices()` eventually associates it with the local cluster. This causes Elasticsearch to fallback to the local cluster unknowingly and return its details back to the user even though the user hasn't requested any info about the local cluster.

pawankartik-elastic · 2025-06-03T15:46:38Z

Ugh, backport tool is broken. I'll manually do the porting tomorrow morning.
Edit: Used an older version of backport. Things looking good.

pawankartik-elastic · 2025-06-03T16:03:17Z

💚 All backports created successfully

Status	Branch	Result
✅	9.0
✅	8.18

Questions ?

Please refer to the Backport tool documentation

…ster name (elastic#128610) The auth code injects the pattern `["*", "-*"]` to specify that it's okay to return an empty response because user's patterns did not match any remote clusters. However, we fail to recognise this specific pattern and `groupIndices()` eventually associates it with the local cluster. This causes Elasticsearch to fallback to the local cluster unknowingly and return its details back to the user even though the user hasn't requested any info about the local cluster. (cherry picked from commit 3f1e1b3) # Conflicts: # server/src/main/java/org/elasticsearch/transport/RemoteClusterService.java

…ster name (#128610) (#128843) The auth code injects the pattern `["*", "-*"]` to specify that it's okay to return an empty response because user's patterns did not match any remote clusters. However, we fail to recognise this specific pattern and `groupIndices()` eventually associates it with the local cluster. This causes Elasticsearch to fallback to the local cluster unknowingly and return its details back to the user even though the user hasn't requested any info about the local cluster. (cherry picked from commit 3f1e1b3) # Conflicts: # server/src/main/java/org/elasticsearch/transport/RemoteClusterService.java

…ster name (#128610) (#128842) The auth code injects the pattern `["*", "-*"]` to specify that it's okay to return an empty response because user's patterns did not match any remote clusters. However, we fail to recognise this specific pattern and `groupIndices()` eventually associates it with the local cluster. This causes Elasticsearch to fallback to the local cluster unknowingly and return its details back to the user even though the user hasn't requested any info about the local cluster. (cherry picked from commit 3f1e1b3)

…ster name (elastic#128610) The auth code injects the pattern `["*", "-*"]` to specify that it's okay to return an empty response because user's patterns did not match any remote clusters. However, we fail to recognise this specific pattern and `groupIndices()` eventually associates it with the local cluster. This causes Elasticsearch to fallback to the local cluster unknowingly and return its details back to the user even though the user hasn't requested any info about the local cluster.

Handle the indices pattern ["*", "-*"] when grouping indices by clu…

b3c3f9d

…ster name

elasticsearchmachine added the v9.1.0 label May 29, 2025

smalyshev approved these changes May 29, 2025

View reviewed changes

javanna reviewed Jun 2, 2025

View reviewed changes

server/src/main/java/org/elasticsearch/transport/RemoteClusterService.java Outdated Show resolved Hide resolved

pawankartik-elastic added 3 commits June 2, 2025 10:50

Apply review comments

cd388ae

Drop redundant code comment

d29a9c3

Merge branch 'main' into pkar/detect-no-indices-aliases-pattern

7a76fca

pawankartik-elastic added >bug Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch :Search Foundations/CCS v8.19.0 v9.0.3 v8.18.3 labels Jun 2, 2025

pawankartik-elastic marked this pull request as ready for review June 2, 2025 11:05

Update docs/changelog/128610.yaml

bac027a

pawankartik-elastic added the auto-backport Automatically create backport pull requests when merged label Jun 2, 2025

javanna approved these changes Jun 2, 2025

View reviewed changes

pawankartik-elastic added 2 commits June 3, 2025 11:15

Apply review comments

00020a3

Merge branch 'main' into pkar/detect-no-indices-aliases-pattern

07449bb

pawankartik-elastic merged commit 3f1e1b3 into elastic:main Jun 3, 2025
18 checks passed

pawankartik-elastic mentioned this pull request Jun 3, 2025

[8.19] Handle the indices pattern ["*", "-*"] when grouping indices by cluster name (#128610) #128822

Merged

elasticsearchmachine added the backport pending label Jun 3, 2025

This was referenced Jun 3, 2025

[9.0] Handle the indices pattern ["*", "-*"] when grouping indices by cluster name (#128610) #128842

Merged

[8.18] Handle the indices pattern ["*", "-*"] when grouping indices by cluster name (#128610) #128843

Merged

pawankartik-elastic deleted the pkar/detect-no-indices-aliases-pattern branch June 26, 2025 14:03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Handle the indices pattern `["", "-"]` when grouping indices by cluster name #128610

Handle the indices pattern `["", "-"]` when grouping indices by cluster name #128610

Uh oh!

pawankartik-elastic commented May 29, 2025

smalyshev commented May 29, 2025

smalyshev commented May 29, 2025 •

edited

Loading

pawankartik-elastic commented May 29, 2025 •

edited

Loading

pawankartik-elastic commented May 29, 2025

Uh oh!

elasticsearchmachine commented Jun 2, 2025

elasticsearchmachine commented Jun 2, 2025

javanna left a comment

javanna Jun 2, 2025

pawankartik-elastic Jun 3, 2025

Uh oh!

elasticsearchmachine commented Jun 3, 2025

pawankartik-elastic commented Jun 3, 2025 •

edited

Loading

pawankartik-elastic commented Jun 3, 2025

Labels

4 participants

Handle the indices pattern ["*", "-*"] when grouping indices by cluster name #128610

Handle the indices pattern ["*", "-*"] when grouping indices by cluster name #128610

Uh oh!

Conversation

pawankartik-elastic commented May 29, 2025

smalyshev commented May 29, 2025

smalyshev commented May 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

pawankartik-elastic commented May 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

pawankartik-elastic commented May 29, 2025

Uh oh!

elasticsearchmachine commented Jun 2, 2025

elasticsearchmachine commented Jun 2, 2025

javanna left a comment

Choose a reason for hiding this comment

javanna Jun 2, 2025

Choose a reason for hiding this comment

pawankartik-elastic Jun 3, 2025

Choose a reason for hiding this comment

Uh oh!

elasticsearchmachine commented Jun 3, 2025

💔 Backport failed

pawankartik-elastic commented Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

pawankartik-elastic commented Jun 3, 2025

💚 All backports created successfully

Questions ?

Labels

4 participants

Handle the indices pattern `["", "-"]` when grouping indices by cluster name #128610

Handle the indices pattern `["", "-"]` when grouping indices by cluster name #128610

smalyshev commented May 29, 2025 •

edited

Loading

pawankartik-elastic commented May 29, 2025 •

edited

Loading

pawankartik-elastic commented Jun 3, 2025 •

edited

Loading