Nginx reverse proxy for Kibana : cannot authenticate

Elastic Stack Kibana
1

Hi,

I'm currently trying to set a CNAME to a Clouded Kibana. In my attempt to do so, i contacted the support (during the trial period) who was kind enough to confirm that i needed a reverse proxy to work the problem and make the CNAME point to the said reverse proxy - see link bellow :

I'm currently working on a reverse proxy via nginx. After configuring the proxy, whenever i try to access Kibana i get the following message

{"statusCode":401,"error":"Unauthorized","message":"[security_exception] unable to authenticate user [elastic] for REST request
 [/_xpack/security/_authenticate], with { header={ WWW-Authenticate={ 0=\"Bearer realm=[\\\](file:///)
"security[\\\](file:///)"\" & 1=\"ApiKey\" & 2=\"Basic realm=[\\\](file:///)"security[\\\](file:///)"
 charset=[\\\](file:///)"UTF-8[\\\](file:///)"\" } } }"}

I tried to authenticate via curl but i get the same error after being asked for my password

After researching the issues thanks to the following links :

I understand that i need to update the kibana.yml file or set some x-pack configurations.

Could you explain how i'm suppose to do so on Elastic Cloud ?
Is there a way to work the problem through the dev console or should i set the file via curl ?
Could you give me additional insights on how to do so ?

Thanks in advance !

2

@IanCap, what does your proxy configuration look like?

3

Thanks for helping me !

My configuration looks like this :

events {
}

http {
  upstream elasticsearch {
      server {instance-name-with-region}.aws.cloud.es.io:9243;
      keepalive 15;
  }

  server {
      listen 443 ssl;
      ssl_certificate /usr/local/etc/openssl@1.1/certs/self-signed.crt;
      ssl_certificate_key /usr/local/etc/openssl@1.1/private/self-signed.key;

      location /dashboard/ {
        proxy_pass https://elasticsearch;
        proxy_http_version 1.1;
        proxy_set_header Connection "Keep-Alive";
        proxy_set_header Proxy-Connection "Keep-Alive";
        proxy_set_header Authorization "Basic {base64 of {username:password}}"; 
        proxy_set_header Host {instance-name-with-region}.aws.cloud.es.io:9243;
      }
  }
}

I'm using a self certificate
The nginx runs on my localhost for testing

4

Thanks! I didn't bother with SSL locally, but I was able to get the following to work for my test cloud instance. My test instance was created a while ago, so ignore the difference in domain name.

Unnecessary, but I also renamed the elasticsearch upstream entry to kibana to better reflect what we're actually connecting to:

http {
  upstream kibana {
      server {instance}.us-east-1.aws.found.io:9243;
      keepalive 15;
  }

  server {
      listen 8080;
      #ssl_certificate /usr/local/etc/openssl@1.1/certs/self-signed.crt;
      #ssl_certificate_key /usr/local/etc/openssl@1.1/private/self-signed.key;

      location / {
        proxy_pass https://kibana;
        proxy_http_version 1.1;
        proxy_set_header Connection "Keep-Alive";
        proxy_set_header Proxy-Connection "Keep-Alive";
        proxy_set_header Authorization "Basic dGVzdDpjaGFuZ2VtZQ==";
        proxy_set_header Host{instance}.us-east-1.aws.found.io:9243;
      }
  }
}

Those credentials above decode to test:changeme, but set this to whatever you need for your cluster.

Can we try to simplify your configuration to match mine, see if it works, and re-introduce the changes 1 by 1?

  • Remove /dashboard/ from the location match
  • Remove SSL on the client side, moving off of port 443 as well for clarity
5

After changing the configuration to match yours, i get the exact same issue

{"statusCode":401,"error":"Unauthorized","message":"[security_exception] unable to authenticate user [elastic] for REST request [/_xpack/security/_authenticate], with { header={ WWW-Authenticate={ 0=\"Bearer realm=\\\"security\\\"\" & 1=\"ApiKey\" & 2=\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\" } } }"}

Does the basic64 should authenticate to match an Elastic account or a Kibana account ?

6

The elastic account that the Cloud admin console creates for you should work for both Kibana and Elasticsearch. My only advice is to double check those credentials.

If you base64-decode the username and password, can you login to Kibana with those credentials if you navigate there directly (bypassing the proxy)?

7

To log in to ES, i have to use my email address and for kibana i have the elastic account that the Cloud admin console created for me, so i have 2 different accounts for ES and Kibana

If i base64-decode the username:password i can indeed log in Kibana on the connexion panel

Maybe there is something to change on the Kibana side ?
When i do the following :

GET _xpack/security/_authenticate

I get :

{
  "username" : "elastic",
  "roles" : [
    "superuser"
  ],
  "full_name" : null,
  "email" : null,
  "metadata" : { },
  "enabled" : true,
  "authentication_realm" : {
    "name" : "found",
    "type" : "file"
  },
  "lookup_realm" : {
    "name" : "found",
    "type" : "file"
  }
}

I created a second user in kibana, shouldn't it shows here ?

8

As far as I know, the account with your email address should just be needed to authenticate to the Cloud Admin Console. The elastic user account should work for both Kibana and Elasticsearch (Kibana delegates all auth to Elasticsearch, there are no separate accounts between the two).

There shouldn't be any changes required on the Kibana side. You mentioned you created another user. If you run GET /_xpack/security/user, it should show you all of the users that you created

9

Indeed i see the users i created

I guess i have an issue linked to my deployment since it works on your side with the configuration you gave me
The version is in 6.8.8.

I'll try on an other deployment and then from an other terminal, maybe the issue comes from here

Could we leave this tread open so i can keep you posted ?

Thanks a lot for taking time to help me on this issue

10

I think this will eventually auto-close (I don't control that), but please do keep me posted. Happy to help out if I can

11

Hi,

A solution has been found and it was simple yet strange :
I encoded the base64 username:password with openssl
Our CTO used an other solution : https://www.base64encode.org/
and it worked !

Apparently the algorithms are different, it might be worth writing this possible issue with openssl somewhere

Also, we managed to make it work with tokens

Thanks a lot for taking time on this, i can now move on other issues !

12

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.