NGINX Reverse Proxy - Not Proxy Auth

1

I am trying to setup ROR Enterprise behind an NGINX reverse proxy for load blancing across multiple backend/upstream servers but am stuck with the same/similiar issues described in Using nginx reverse proxy for readonlyrest pro
Tho unlike it I am not trying to replace the ROR authentication with NGINX.

Using the nginx config

    location /kibana {
        proxy_pass https://kibana;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

results in a 404 with a url of https://proxyserveraddress/login?next=/kibana/. Navigating to https://realdeviceaddress/kibana presents the same url response, though without the 404 error. This make sense since its not going through the proxy, though the added ?next=/kibana is confusing me.

Setting the server.basePath property in the kibana.yml file to "/kibana" should resolve the issue however in by doing so ROR enters an infinite loop.

I’m not sure what I am missing or misunderstanding for this to function. Most of the result in the forums in regards to proxy use only refer to use proxy-auth. If there are any examples or explanations on how to operate this correctly it would be appreciated.

2

Hi Matthew, can you check what infinite loop? I.e. from chrome dev tools. What URLs are you being bounced back and forth from/to.

3

login?next=/kibana/kibana/login

(NGINX)

image
image.png1891×970 103 KB

(DIRECT)

image
image.png1892×930 94.4 KB

4

So i was messing around and i think i figured out what’s going on. On NGINX I altered the location statement to:

    location /kibana/ {
        proxy_pass https://kibana/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

This meant that the location /kibana set via nginx no longer gets forwarded to the proxy destination server and in theory it should return a 404 Not Found error since the server.basePath was changed … however it presented a rendered ROR login page. This means that ROR is responding on https://realdeviceaddress:5601/login and not on what I assumed would be https://realdeviceaddress:5601/kibana/login. Sure enough navigating directly to https://realdeviceaddress:5601/login revealed the ROR login page … though not entirely rendered.

image
image.png1885×950 112 KB

Logging into https://proxyserveraddress/kibana/login works perfectly because Kibana is responding with the prefix /kibana on its redirects and NGINX is no longer enforcing it on the login call.


Using https://realdeviceaddress:5601/login to login successfully results in the same redirect loop as if you were attempt to access https://realdeviceaddress:5601/kibana/login. This is because the response from the server is appending /kibana to the redirects. So while going to https://realdeviceaddress:5601/login presents the a login page, logging in still has redirects affected by the server.basePath and alters the calls to https://realdeviceaddress:5601/kibana/login … which does not exist.


Given that I am not aware of the inner workings of the ROR plugin or which calls are made, how, or when my assumption is that the user is not actually authenticated or given the appropriate tokens needed to be considered logged in. Since navigating to the root of kibana, in the case the altered server.basePath, https://realdeviceaddress:5601/kibana the user is redirected to https://realdeviceaddress:5601/kibana/login. Thus the redirect loop occurs.


Looking back at the non-rendered logo image we can see that the attempted url to retrieve the image was https://realdeviceaddress:5601/kibana/plugins/readonlyrest_kbn/img/readonlyrest-logo-white.png. If altreted to https://realdeviceaddress:5601/plugins/readonlyrest_kbn/img/readonlyrest-logo-white.png the images loads. This suggests that this is not solely related to /login.


Is this the expected behaviour or is ROR not appropriately accounting for server.basePath?

5

Hi @mgaetano, sorry for the delayed response. The issue is reproduced. Something has changed in how Kibana as a platform delivers static content VS how it delivers API routes when you use basePath. Will need to put together a minimal code example to report as a bug for the Kibana team to have a look.

6

Yesterday I submitted the bug, let’s see what they say

7

Hello @sscarduzio,

Do you have news about this bug?

Regards
H

8

We have an engineer finally on this right now.

9

Hi @mgaetano,
The server.basePath property in the kibana.yml file is meant to be used solely with a proxy, even though the name of the property is somewhat confusing.

Adding server.basePath: "/kibana" to your kibana.yml will make request URIs generated by kibana to be prefixed by that base path. That way you can set kibana up in a specific path, such as my.site/kibana. However, you still need to remove that prefix in nginx when passing the request on to kibana.

That said it is worth noting that - just as kibana itself - RoR should either be used with a proxy or without one, but not both ways simultaneously. In the example you posted, you could access RoR on https://realdeviceaddress:5601/login but it didn’t work properly, because RoR added the /kibana prefix, but it was not accessed through proxy, so there was nothing to “strip it off”. If you need more details, here’s a more thorough discussion on a similar problem (not about RoR, but kibana itself, however RoR complies with that assumption): Nginx reverse proxy setup for Kibana - Kibana - Discuss the Elastic Stack

I can see that you figured out the correct nginx configuration, but for the record, this should work:
location /kibana/ { proxy_pass https://kibana/; ... }

Let us know if you need help with anything else.