Standard basic auth URL not working with Kibana 3

[teu]

Hi,

I have secured elasticserch after an apache forward proxy with basic authentication. I am setting a standard URL into kibana's config.js:

elasticsearch: "http://user:pass@host:port",

Looking at the URLs however that are used in the requests, doesn't seam like the authentication is used in them. Seams like a bug as it prohibits using some levels of security for elasticsearch.

[bobrik]

I had the same issue, fixed it with whitelisting dev/trusted ip addresses. ssh port forwarding is a solution too, but more complex.

[teu]

Hi,
yes, I have in behind AWS firewall but still, it;s not very flexible.

[rashidkpc]

Don't use the user:pass syntax, especially not in config.js, as anyone can read that and most browsers don't support it anyway. The browser will simply prompt the user for it.

[teu]

This is a standard syntax http://tools.ietf.org/html/rfc3986#section-3.2.1, but if you know any browsers that don't work well with URL's please point them out, also if the password is the same as kibana - doesn't matter if the user reads it as he would already know it... that's the whole point.

[bobrik]

If you expose elasticsearch at the same port, browser will use user+pass, entered for kibana itself. If you use different port to access elasticsearch, there could be problems.

[teu]

So you say, the solution is to make Kibana with basic realm authentication on let's say port 80, and have a a proxypass from localhost:80/[customElasticsearchDIR] to localhost:9200 with the same ?

[rashidkpc]

The format was deprecated 8 years ago. IE hasn't supported it since IE6. Firefox no longer supports it by default, Chrome started to remove it in version 19. bobrik is correct, run it on the same port and you'll be fine. See the sample/ directory of this repository for example apache and nginx configurations

From your link, 2nd paragraph (http://tools.ietf.org/html/rfc3986#section-3.2.1):
Use of the format "user:password" in the userinfo field is deprecated. Applications should not render as clear text any data after the first colon (":") character found within a userinfo subcomponent unless the data after the colon is the empty string (indicating no password). Applications may choose to ignore or reject such data when it is received as part of a reference and should reject the storage of such data in unencrypted form. The passing of authentication information in clear text has proven to be a security risk in almost every case where it has been used.

[bobrik]

@teu, kind of. We have kibana on http://host/ and elasticsearch on http://host/es, but we use nginx.

[teu]

@rashidkpc I'll give you that, didn't read it carefully enough. Seams like with @bobrik fix it won't be an issue anymore. Thanks.

@bobrik Thanks, will try that :)

[theflofly]

If the config.js file and the Kibana website is only accessible after an authentification. I don't think that put the user and password into the elasticsearch server url is a problem. It would be pretty convenient.