6.4.0-SNAPSHOT fails get all aliases with security enabled and no indices exist

[dakrone]

Due to: #31308

There is an issue with security when retrieving all aliases and no indices exist.

Reproduction:

• Use a 6.4.0-SNAPSHOT build with xpack.security.enabled: true in elasticsearch.yml
• Configure a file realm user with superuser role
• Start elasticsearch and start an x-pack trial
• Then attempt to retrieve all aliases:

~/elasticsearch-6.4.0-SNAPSHOT λ curl -XGET -u"foo:bar" "localhost:9200/_aliases"
{}
~/elasticsearch-6.4.0-SNAPSHOT λ curl -XPOST "localhost:9200/_xpack/license/start_trial?acknowledge=true"
{"acknowledged":true,"trial_was_started":true,"type":"trial"}
~/elasticsearch-6.4.0-SNAPSHOT λ curl -XGET -u"foo:bar" "localhost:9200/_aliases"
{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","index_uuid":"_na_","index":"_all"}],"type":"index_not_found_exception","reason":"no such index","index_uuid":"_na_","index":"_all"},"status":404}

With 38b1a5f reverted, the correct behavior can be seen:

~/elasticsearch-6.4.0-SNAPSHOT λ curl -XGET -u"foo:bar" "localhost:9200/_aliases"
{}
~/elasticsearch-6.4.0-SNAPSHOT λ curl -XPOST "localhost:9200/_xpack/license/start_trial?acknowledge=true"
{"acknowledged":true,"trial_was_started":true,"type":"trial"}
~/elasticsearch-6.4.0-SNAPSHOT λ curl -XGET -u"foo:bar" "localhost:9200/_aliases"
{}

[elasticmachine]

Pinging @elastic/es-core-infra

[javanna]

@dakrone are you sure that you get the same behaviour with get mappings? I wouldn't expect that.

There are limitations when security is enabled, that are documented in our docs: "While creating or retrieving aliases by providing wildcard expressions for alias names, if there are no existing authorized aliases that match the wildcard expression provided an IndexNotFoundException is returned.". The get aliases API is subject to this.

Before #31308 the get alias API didn't require indices:admin/aliases/get privileges when called without specifying indices and aliases, as it would internally be converted to an indices:admin/get (get index API) action. I find this a bug, as any alias was returned, while going through the get alias API we would also look at which aliases the user is authorized for and we replace them in the request. Whenever replacing aliases (not specifying aliases gets converted to _all which with security enabled means "all of the aliases that the user has access to"), the problem described above comes up, that when there are no aliases in the cluster the security plugin will throw a 404 instead of returning an empty response.

In hindsight, this is the behaviour that we should have always seen from the get alias API, in fact before removing RestGetAllAliasesAction there used to be a difference between doing GET /_alias/_all compared to GET /_alias which makes the behaviour inconsistent. Users would expect the same behaviour as they refer to the _alias endpoint as the get alias API.

This could be seen as a regression, but my personal opinion is that it was a bugfix and this behaviour, although not desirable, is known and documented, it was a mistake that the API didn't behave consistently depending on the provided parameters.

We can look as a follow-up at possibly improving this overall behaviour of the get alias API, similar to what we did in 5.0 for indices (we used to have the same limitation around indices but that was fixed), I think we have a way now to remove this limitation for the get alias API in 7.0.

[dakrone]

@dakrone are you sure that you get the same behaviour with get mappings? I wouldn't expect that.

Just tested this and it does appear to only affect aliases, I'll change the title/body

This could be seen as a regression, but my personal opinion is that it was a bugfix and this behaviour, although not desirable, is known and documented, it was a mistake that the API didn't behave consistently depending on the provided parameters.

I think this needs to go into the migration documentation and be marked as a breaking change then, since it did break something (Kibana). I can see how it can be considered a bugfix, but at the same time I think we should strive to be as consistent as possible for a non-security versus security installation

We can look as a follow-up at possibly improving this overall behaviour of the get alias API, similar to what we did in 5.0 for indices, I think we have a way now to remove this limitation for the get alias API in 7.0.

👍

[javanna]

@jaymode what's your take on this?

I am open to reverting the change on 6.x and working on master to possibly remove the limitation completely. Otherwise we can keep the change in 6.x and document the different behaviour starting from 6.4 as Lee suggested, it's more consistent but breaking and undesired.

[javanna]

I looked at removing the get alias limitations with security installed on master, and it is not as easy as it was with indices, the reason being that we don't support alias exclusions, hence there is no safe way to send a request through making sure that no aliases will be returned. In fact if there are no matching authorized aliases, we can't replace the aliases with an empty list of aliases as that would mean all aliases once the request is executed by Elasticsearch, which would lead to returning unauthorized aliases. With indices we replace them with an exclusion expression that always resolves to no indices, but given that we don't support aliases exclusions, it is not possible to do the same with aliases.

[jaymode]

I'm personally in favor of reverting so we don't having a breaking API change in a minor. I don't have an idea right now on how we could fix this; I'll need to look at it some more.

[javanna]

#31308 was reverted on master to prevent any breakage in a minor version. We are looking at removing the get aliases limitations on master.