There is not a single individual place I could point you too. You basically would need to look at every place in Kibana, that requires data from Elasticsearch and add the headers there. Meaning these are at least all different visualization types, index patterns, etc.
You can search the source code for
callWithRequest which will be called on the Kibana server to send the request to Elasticsearch. And then check from that places, which client side call actually triggered them and add your headers to that call.
For me that sounds like you will be busy the next few months with this, why I wouldn't consider that a viable solution (and also basically every update would break your code again).
If I look what you trying to achieve, I would rather suggest another approach where you might be able to use way less code modifications.
I would set those parameters on the client side (where as far as I understood you need to calculate them) into a cookie for the Kibana domain. That way they will be automatically send to every call against the Kibana server in the cookie header, and you don't need to manually attach them.
Then I would just modify the
callWithRequest method, that it extracts the params you need from the cookies of the
req variable again and attach them to the headers of the actual request.
However, you should be aware that you are really digging a lot in Kibana internals, and that this will mean, that a) most likely you won't survive a single update with new code modifications and retest and b) you most likely will cause weird behavior, since not every call that Kibana does against Elasticsearch is actually triggered by a call from the browser to the Kibana server. Meaning some of the calls that will hit your Elasticsearch (or more specific your proxy) will still not have any of those headers, since they were never triggered by any call from the browser and thus have no cookie information in them.