So, this is our use case:
We have multiple dashboards with three levels of access.
First, we have dashboards that we want to go public, we aim to embed them onto our webpage and allow everyone to see them. Those dashboards are on a space where just the anonymous login enabled user has access. We would like to reduce and simplify links to these dashboards through an Apache reverse proxy, as they won't be only reached through the web embedding, they'll also be shared through links. Using a reverse proxy we simplify the links and can change the dashboards without changing public urls, as we can redirect the reverse proxy to a different url.
Second, we have some dashboards we want to make public at an enterprise level. Those will be embeded on intranet sites and also shared through urls, there is no problem with users that reachs one of them being able to see all. These are on a space where there is a specific user who has access. We plan to reverse proxy those also, passing authentication credentials of this user on the proxy redirection and enforcing requests to come from within our internal net.
Finally, we'll have other dashboards that we want to be reachable only for us, those will be on a third space, where only development users are allowed to access, and usually we'll access those directly by kibana UI.
So we're aiming to do a lot of proxy reverse redirections through Apache. Mainly with two possible configurations: one to access those dashboards on the public space and another to access those on company level space.
Do you see any problem with our approach to the use case?
Currently we're on the first stage, trying to allow access to public dashboards through reverse proxy, and we're facing some difficulties.
On our apache default-ssl.conf file, within virtual host to manage https calls, we have the following code to redirect calls to a dashboard:
SSLProxyEngine on
<Location /city>
ProxyPass https://<lengthy-public-shared-url-to-dashboard>
ProxyPassReverse https://<lengthy-public-shared-url-to-dashboard>
RequestHeader set Authorization "Basic <base 64 coded anonymous user authentication>"
</Location>
With this, when we try to reach https://our-domain-kibana/city we are being somewhat correctly redirected, but we only get a blank page, although looking into it's source code we can see lot of code from kibana site is being loaded (also we see some references to correct space, so we think we are on the right way).
We don't get errors on apache logs, but on browser console we get a bunch of errors regarding "Failed to load resource: the server responded with a status of 404" (for bootstrap.js) or "Refused to execute script from https://our-kibana-domain/s/public-space-name/bootstrap.js because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled."
We are a bit of lost here, and didn't found much reliable info on the matter. Any help would be highly appreciated.
EDIT1: Whatching Apache access.log I'm seeing that several urls within kibana are returning 404 errors:
/66491/bundles/kbn-ui-shared-deps-npm/kbn-ui-shared-deps-npm.v8.light.css
/node_modules/@kbn/ui-framework/dist/kui_light.min.css
/s/our_space_name/bootstrap.js
...
Seems like those files aren't being reached after reverse proxy redirection, I wonder if this is somewhat related to kibana basePath? We've not added a basePath at this point.
EDIT 2: Well... seems that the proxy redirection from /city to our dashboard was ok, but different resources urls were losing port 5601 on the translation, so I added a reverse proxy from / to https://our-kibana-domain:5601 and 404 problems seems to dissapear.
Seems that now we have some problem with authentication, as bootstrap.js which previously returned a 404 error is now returning a 401 error, so now it's being reached, but for some reason, it's not being allowed to execute
EDIT 3: Step by step I'm finding some clues about what is happening. Seems like when accessed from the reverse proxy, bootstrap.js on the space url arrives with content-type: application/json, while if it's accessed directly it arrives with content-type: application/javascript. This is what is preventing bootstrap.js to being executed.
In the end, the reason why this was happening was that the url that kibana provides to share a dashboard includes several URL encoded characters, those seemed to somewhat tamper with the content-type. Once I changed those characters on the proxy redirection the problem dissapeared.
Now I'm getting something new:
Detected an unhandled Promise rejection.
Message: Forbidden
Stack: Error: Forbidden
At core.entry.js
This messages appeared at kibana.log:
{"service":{"node":{"roles":["background_tasks","ui"]}},"ecs":{"version":"8.6.1"},"@timestamp":"2024-09-13T13:06:20.548+02:00","message":"User not authorized for \"/internal/uptime/index_status?from=now-7d&to=now\": responding with 403","log":{"level":"WARN","logger":"plugins.security.api-authorization"},"process":{"pid":136804},"trace":{"id":"048c9bd0c1eff5ed9dc22b204a4c2a81"},"transaction":{"id":"8de4c35fa0a0ac3a"}}
{"service":{"node":{"roles":["background_tasks","ui"]}},"ecs":{"version":"8.6.1"},"@timestamp":"2024-09-13T13:09:00.977+02:00","message":"Running Fleet Usage telemetry send task","log":{"level":"INFO","logger":"plugins.fleet"},"process":{"pid":136804},"trace":{"id":"e8d2859ce80d81ff3b54b5b136a3f874"},"transaction":{"id":"81f9e32416d46e97"}}