why?

We talked a bit about this on slack tonight, and the consensus from that discussion at least was:

We make this option configurable, but we leave the default value as true (ie. blocking access). This is consistent with the default behaviors of ES/shield in general, which is that you don't have access unless you explicitly give it.

Handling this type of thing via a generic config value is kind of lame, but it's probably the only practical option in the short term until we have a more robust authorization system built into Kibana itself.

jenkins, test it

jenkins, test it

Linting issues here

statusPage.disableAuth needs to be documented somewhere. It doesn't make sense to put it in the config file since there's no built in auth, should probably go in the docs somewhere.

Though disableAuth is specific to Kibana rather than security - it will affect any plugin that ties into hapi's auth system.

I don't want to clutter the config file with references to rarely used settings in any case

Agreed.

This seems to work as described, but I would consider removing the double negation implied by disableAuth. Perhaps allowUnauth (almost as bad) or allowAnonymous?

I never really understood the whole aversion to negative flags, but if you're both in agreement about it, I certainly don't care. That said, definitely something like allowAnonymous instead of allowUnauth.

Wait for the build to finish and merge it