Ok, I can explain. I apologize for any previous misunderstanding. When upgarding KBN from 7.17.X to 8.X, I wanted to preserve a few separate kibana instances(with its settings/saved_objects/visualizations/dashboards) by using kibana.index (in kibana.yml) instead of merging them to one common kibana(with default “kibana.index” .kibana) and separate with the only one officially supported option by Kibana, Spaces.
Thanks to Readonlyrest it works very well. Just reporting module(and report download) seems to be having some problems in my case 
My suspicion is that this Reporting issue is related to using different Kibana index names on different Kibana instances, combined with how Kibana/ES handle and coordinate reporting jobs.
Even if that’s not the root cause, the example I posted still stands: it shows the configuration required for Reporting to work reliably with multiple Kibana instances.
Thank you very much. I think that reporting in KBN 7.X with multitenant configuration could much rely on these parameters “xpack.task_manager.index & xpack.reporting.index“ that are not available in 8.X and users like me, should move to recommended Spaces
Hi again,
I checked report generation and download with only one active kibana instance using default .kibana_index(not using kibana.index in kibana.yml) and the reports are being properly Processed by THAT kibana instance but I am still not able to download it via kibana GUI with installed KBN ROR. Using kibana 8.19.7(without ROR) connected to ES node 8.19.7(without ROR) [within the same Elastic cluster], everything is working okay either in “Default” space or the other ones I have.
Could you please check and verify it again on your side with 8.19.7 and ROR 1.68? I do not have any idea what could I have especially different.
Yes, we will check it. But probably not this week, because we are working on closing ROR 1.69.0 release-related tasks.
Hi, have you had any ‘time slot’ to check this case?
Sorry, not yet. We will take care of it after ROR 1.69.0 release. We do our best to release it this week.
Hello @mikeIT
Sorry for the delay. I was able to reproduce this issue only when I configured kibana.index it in kibana.yml, However, it’s not your case. Here is a working example (instructions for running it are in the description). Please also check this configuration.
In my configuration for kibana I do not use “server.ssl.*“.
Here Cannot download generated report for kibana 8.19.7 - #24 by mikeIT I just tried to check if this was really the problem.
So I still use “kibana.index“ (but plan to change it 
) with additional parameters:
xpack.reporting.encryptionKey: XXX
xpack.encryptedSavedObjects.encryptionKey: YYY
xpack.security.encryptionKey: ZZZ
*All with the same values across multiple kibana instances.
The problem is just with report download when ROR is installed.
For KBN(without kibana.index)+ES, both without ROR, it’s okay and I can download the reports generated using other kibanas(with kibana.index).
Yes, as I see, there is a problem with correct handling kibana.index In this case, for 8.x version. I also checked 9.3.x version, and it works as expected
Hello @mikeIT
I prepared a pre-release build with a fix of this issue with an report download https://readonlyrest-data.s3.eu-west-1.amazonaws.com/tmp/mikeit/readonlyrest_kbn_universal-1.70.0-pre1_es8.19.7.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5SJIWBO5STIUBEAP%2F20260410%2Feu-west-1%2Fs3%2Faws4_request&X-Amz-Date=20260410T114143Z&X-Amz-Expires=604800&X-Amz-Signature=f1cd23a2d72c20f03d0f3e1f5cc1b6a2c794d7d7381652df9cc687643f9ee6b9&X-Amz-SignedHeaders=host. It’s compatible with ReadonlyREST ES 1.69.0 version or above
Hi,
I’ve just checked ‘KBN pre-release build 1.70‘ for one kibana instance and one ES node(ROR 1.69.1) and everything seems to be working okay
2 Likes