Does X-Pack perform authorization checks per index or shard on every request?

Elastic Stack Kibana
1

Hi,

I'm currently managing an Elasticsearch cluster with X-Pack security enabled. Our setup includes approximately 6,400 indices and 23,200 shards.

Right after I activated xpack, Elasticsearch's performance became extremely slow, even though it was working perfectly fine before.

I have a couple of questions regarding how X-Pack handles authorization:Discuss the Elastic Stack

  1. Authorization Checks:
    When a user sends a query, does X-Pack perform authorization checks on a per-index or per-shard basis for each request? In other words, are permissions verified individually for each index or shard involved in the query?
  2. Performance Impact:
    Given the large number of indices and shards in our cluster, could this per-index or per-shard authorization checking lead to significant performance degradation? If so, are there recommended strategies to mitigate this impact?

I've come across discussions suggesting that authorization is enforced for each operation and that distributed requests are subject to these checks at each stage. However, I would appreciate more detailed insights or official documentation references on this matter.

Any guidance or experiences shared would be highly valuable.

Thank you in advance!

2

which elasticsearch version please? And my guess is your cluster has a number of master/data nodes?

Just to be sure, can you be explicit on your steps to "activate xpack", i.e. what and where did you change what specifically?

3
  • Elasticsearch version: 7.13.3
  • Cluster topology: 3 master-eligible nodes
  • X-Pack security settings (applied identically on all three nodes):

yaml

xpack.security.enabled: true

# Enable SSL for transport (node-to-node) communications
xpack.security.transport.ssl.enabled: true
xpack.security.transport.filter.allow: [ "10.10.200.123", "10.10.200.124", "10.10.200.125" ]
xpack.security.transport.filter.deny: _all

xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/elastic-certificates.p12
xpack.security.transport.ssl.client_authentication: required

# HTTP (REST) interface SSL is turned off
xpack.security.http.ssl.enabled: false

Certificate generation:
/usr/share/elasticsearch/bin/elasticsearch-certutil cert
-out config/elastic-certificates.p12
-pass ""

  1. Copied the generated elastic-certificates.p12 to /etc/elasticsearch/ on each master node.
  2. Restarted all three nodes.
  3. Waited until all shards were in the ACTIVE state.
  4. Created the superuser account via the Elasticsearch API.

The services connected to Elasticsearch are currently accessible. Functionally, everything works fine, but the issue is that Elasticsearch is too slow.

4

So, I hope someone else with more knowledge on the relevant code paths helps, but

might be relevant to your case (6400 indices sounds like a "large number" to me).

2 Likes
5

I think that the issue that @RainTown linked is very probably related to your case.

According to this comment on it, the recommendation would be to upgrade to at least 7.16.

But this is also an EOL version, I would suggest to upgrade to the last 7.17.X version to also plan the migration to version 8.18.X.

You are running a very olde and unsupported version and it seems that your issue was fixed/improved already.

3 Likes
6

Adding to the great suggestions by @leandrojmp and @RainTown:

What is the output of:

GET /_cat/nodes?v
GET /_cat/indices?v

If some outputs are too big, please share them on gist.github.com and link them here.

How much RAM and HEAP do you have per node?

1 Like