It looks like we have an issue with alias wildcards for group-access permissions since we upgraded the ROR plugin in Elasticsearch and Kibana to v1.49.0.
Which used to work with only the sysgroup_alias-appgroup-loggroup-filegroup1-* wildcard and doesn’t anymore since the upgrade. We added a sysgroup_index-appgroup-loggroup-filegroup1-* wildcard as a workaround now, but we think there might be a bug (re-)introduced.
The alias name contains several dashes which might be the problem since we see that aliases with less of them don’t seem to suffer of this behavior.
At the moment I cannot confirm that there is sth wrong with the indices/aliases matching.
But it looks like we need more info from you to try to reproduce your use case:
what ES version do you use?
what ROR version did you use before upgrading to v1.49.0?
do you confirm there was no ES upgrade in the meantime?
what exactly doesn’t work? eg. searching? or maybe index creation, etc?
are you able to show us the FOBIDDEN log from the ES logs?
It should help us with checking what is the problem.
It looks like the log you’re looking for is not in the logs without enabling debug logs; I first need to acquire permission to make modifications in our production system like that. I come back to you for the logs.
But my client was able to reproduce it with the same details as in the original forum message from me; When given group permissions on alias wildcards the tenancy users weren’t able to read the indices anymore after the upgraded to ROR v1.49.0.
And actually it’s not a FORBIDDEN which they get, but a NOT_FOUND whereas they were able to read/find the index before the upgrade with the same permission config.
It’d be great if you could show me the NOT_FOUND log. There is a lot of info in it - this is the most important thing for us to answer clients’ questions like yours.
At the moment I don’t know how to reproduce it. It works as expected in my local env:
curl -kv -u user1:test "http://localhost:19200/sysgroup_alias*/_search"
* Trying 127.0.0.1:19200...
* Connected to localhost (127.0.0.1) port 19200 (#0)
* Server auth using Basic with user 'user1'
> GET /sysgroup_alias*/_search HTTP/1.1
> Host: localhost:19200
> Authorization: Basic dXNlcjE6dGVzdA==
> User-Agent: curl/7.87.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-elastic-product: Elasticsearch
< content-type: application/json; charset=UTF-8
< content-length: 285
<
{"took":2,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":1,"relation":"eq"},"max_score":1.0,"hits":[{"_index":"sysgroup_index-appgroup-loggroup-filegroup1-0001","_type":"_doc","_id":"1","_score":1.0,"_source":{
"test": 1
}
* Connection #0 to host localhost left intact
}]}}
curl -kv -u user1:test "http://localhost:19200/sysgroup_alias-appgroup-loggroup-filegroup1-0/_search"
* Trying 127.0.0.1:19200...
* Connected to localhost (127.0.0.1) port 19200 (#0)
* Server auth using Basic with user 'user1'
> GET /sysgroup_alias-appgroup-loggroup-filegroup1-0/_search HTTP/1.1
> Host: localhost:19200
> Authorization: Basic dXNlcjE6dGVzdA==
> User-Agent: curl/7.87.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-elastic-product: Elasticsearch
< content-type: application/json; charset=UTF-8
< content-length: 285
<
{"took":2,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":1,"relation":"eq"},"max_score":1.0,"hits":[{"_index":"sysgroup_index-appgroup-loggroup-filegroup1-0001","_type":"_doc","_id":"1","_score":1.0,"_source":{
"test": 1
}
* Connection #0 to host localhost left intact
}]}}
I tried to reproduce the behavior in my local environment, but couldn’t reproduce it there myself as well.
Awaiting a meeting with my client to see if there’s a config/way-to-use mismatch somewhere…