Kibana should bind to 0.0.0.0 in dev mode

[thomasneirynck]

Right now, Kibana binds to localhost in dev mode.

It should bind to a numbered port, e.g. 127.0.0.0. This is helpful when testing. If you have multiple VMs trying to connect to Kibana on the parent host, "localhost" resolves to the VM instance, which is not what we want.

See also #7196, which asks for the reverse operation for production-mode.

[Bargs]

I think I may have misspoken when we were talking about this. I think kibana should bind to 0.0.0.0 in dev mode, otherwise VMs won't be able to access kibana on the host. Inside the VM, even 127.0.0.1 will refer to the VM's own loopback interface.

Also, it seems that the server.host config is ignored in dev mode atm. So if people are opposed to the above, we should at least fix it so server.host isn't ignored.

[thomasneirynck]

I will merge work for this with PR #8013.

[thomasneirynck]

@Bargs

server.host isn't ignored strictly speaking. But in dev-mode, server.host is forced to localhost when requiring SSL. I don't think our test cert (test/dev_certs/server.cert) allow anything but localhost (tested this with a few IPs).

e.g. (server errors)

{"statusCode":502,"error":"Bad Gateway","message":"Hostname/IP doesn't match certificate's altnames: \"IP: 127.0.0.16 is not in the cert's list: \""}

[Bargs]

How do we fix that?

[thomasneirynck]

@spalger Any thoughts?

[spalger]

We picked these defaults for the following reasons:

--hostname=localhost in dev:

• in development mode, Kibana is unlikely to require authentication and therefore anyone on your network will have access to your machine and elasticsearch install if they were to listen on 0.0.0.0
• when using pre-baked SSL certificates, the hostname shown in the browser must match the hostname encoded into the cert
• the default workflow for Kibana development is both detailed in the CONTRIBUTING.md and the workflow that the rest of the defaults are optimized for

--hostname=0.0.0.0 in prod:

• in production, Kibana is expected to be protected somehow
• it's also assumed that production installations of Kibana will not be operating on the users machine, but on a remote machine
• all of the code that ships as part of a build has theoretically been checked for correctness, and is considered safe to run accessible to the entire network

---

If you are using a custom setup, changing these values in your kibana.dev.yml file gives you "new defaults" and they are also trivial to change from the command line it that's more your thing. run npm start -- --help for a list of the command line flags, and remember that you can specify any configuration value as a command line flag as well.

[Bargs]

So if I want to test IE11 in dev mode, I need to generate my own certs for my current ip and update kibana.dev.yml? There's gotta be a better option than that.

[spalger]

You can turn off ssl npm run dev -- --no-ssl

[thomasneirynck]

Closing this with won't fix. Any changes to dev can still be made with the kibana.dev.yml/program arguments flags if necessary.

[Bargs]

It's still sad we have to turn off SSL to test IE, but I agree that's a separate issue.

[spalger]

we have to turn off SSL to test IE

If that were true it would be sad.