Kibana: Kibana to bind to localhost by default

[kimchy]

Elasticsearch binds to localhost by default (check the behavior, ti is tricky with ipv4/ipv6), I think that Kibana should do the same.

It was done for security purposes, but a nice side benefit is that also in Elasticsearch, changing the fact that it binds to localhost means it is a "production" deployment, which means certain production level settings can then be enforced.

[Bargs]

👍 for the sensible default, however:

but a nice side benefit is that also in Elasticsearch, changing the fact that it binds to localhost means it is a "production" deployment, which means certain production level settings can then be enforced.

When setting Elasticsearch up in a local development VM I actually found this assumption to be incredibly frustrating. I wanted to expose ES to the host machine, which required binding to the private network that Virtualbox sets up, but I couldn't do that without jumping through a ton of hoops with Elasticsearch's production verifications. The --dev flag has served us pretty well, so I'd want to debate pros/cons before doing anything like that in Kibana.

[kimchy]

@Bargs if vagrant with private network is a case, maybe we can find a way to identify it and do the right thing. There were many talks around --dev flags (or --prod, which makes more sense), eventually, the binding to localhost ended up winning on ES side. Good to learn why.

[Bargs]

vagrant with private network is a case, maybe we can find a way to identify it and do the right thing.

That would be awesome! I suppose there _is_ an argument for consistency across projects, because problems like this can be solved once and then it's solved for the entire stack.

There were many talks around --dev flags (or --prod, which makes more sense), eventually, the binding to localhost ended up winning on ES side. Good to learn why.

I had a feeling that was the case. I'm open to hearing arguments for it, just saying I'll need some convincing ;)

[thomasneirynck]

Created #8010 specifically to address binding in dev mode. This would preserve the advantages of running on numbered ports for testing, but also align Kibana with ES in prod mode (discussed this offline with @Bargs)

[thomasneirynck]

@w33ble Would this interfere with the reporting module?

[w33ble]

Nope. Reporting just uses the server.host config value, so changing it is fine.

[thomasneirynck]

@spalger Any thoughts?

See write-up of why these choices were made here: https://github.com/elastic/kibana/issues/8010#issuecomment-240890379

[thomasneirynck]

The practical result of this change is the following:

• starting up with the default configuration, Kibana would bind to "localhost". When users connect to Kibana from a remote machine (e..g by IP, dns-name), Kibana will not respond. This problem is avoided when Kibana binds to "0.0.0.0", as is the case now.
• Not being able to connect as-is to a web-app server from a remote host is counter-intuitive.

@epixa @LeeDr ; could you weigh in? I think there's a case to be made _not_ to do this, to avoid having users to modify the default config if they want to connect to Kibana from remote computers. @spalger first made this argument (see linked comment above), and it's the reason why we have '0.0.0.0' to begin with.

[LeeDr]

I'd go ahead and make it consistent with Elasticsearch. I also had the learning curve with Elasticsearch when I switched the host on my VM and then had to set the min heap size and some other changes.

But we don't have that issue on Kibana. Users who are just trying it out, or trying out a new build, would probably hit Kibana locally anyway. And when they go to production, it's a very minor change.

We could even make it super-easy by putting both the default "localhost" and the "all interfaces" commented out like;

(now)

# This setting specifies the IP address of the back end server.
# server.host: "0.0.0.0"

(changed)

# This setting specifies the IP address of the Kibana server.
# localhost (default) is only accessible locally, 0.0.0.0 allows remote access
# server.host: "localhost"
# server.host: "0.0.0.0"

[epixa]

I agree with most of what Lee just said, though we shouldn't be encouraging people to bind to 0.0.0.0. If someone knows what they're doing and wants to bind to 0.0.0.0, then they can. Otherwise, we should encourage people to bind to a specific IP address or hostname.

The docs should also be updated to let people know how to bind to external hosts.

[thomasneirynck]

closed with #8010

See PR https://github.com/elastic/kibana/pull/8013

[jasontedor]

I had a feeling that was the case. I'm open to hearing arguments for it, just saying I'll need some convincing ;)

We have a written a blog post explaining our rationale.

[sandstrom]

How would one bind to both 0.0.0.0 and 0:0:0:0:0:0:0:0 (usually shortened to ::)?