Warn when Kibana uses an insecure connection to Elasticsearch

[kobelb]

Problem

Currently, the following functionality in Kibana is dependent on Kibana to ES communication taking place over HTTPS:

1. Any auth providers which rely upon Tokens: token, saml, kerberos, pki
2. Alerting, which relies upon API Keys Elasticsearch no longer requires TLS for API Keys

This restriction is enforced directly by Elasticsearch on those specific APIs. This is somewhat awkward, and ideally we'd always require that Kibana to ES communication take place using TLS. This would make it possible to use the token auth provider as the default instead of basic. Additionally, this would ensure that all authorization credentials sent from Kibana to ES were encrypted.

Proposal 1

Elasticsearch requires that TLS is enabled on the transport layer when running in production mode. Whenever Kibana detects that Elasticsearch has TLS enabled on the transport layer, we can enforce that Kibana to ES communication use HTTPS. The largest hurdle that I see with this approach is determining whether or not TLS is enabled on the transport layer for Elasticsearch. This would be done over HTTP, and be using Kibana's internal server user credentials.

Proposal 2

Otherwise, we could determine whether or not Kibana is in production or dev mode solely using the values from the kibana.yml. If Kibana is communicating with Elasticsearch using a hostname other than localhost or 127.0.0.1 we could use this as an indication that Kibana is in production mode. This is somewhat congruent to the way this is handled in Elasticsearch:

Thus, we consider an Elasticsearch node to be in development mode if it can not form a cluster with another machine via a non-loopback address, and is otherwise in production mode if it can join a cluster via non-loopback addresses.

Note that HTTP and transport can be configured independently via http.host and transport.host; this can be useful for configuring a single node to be reachable via HTTP for testing purposes without triggering production mode

This would mean that as soon as Kibana and Elasticsearch are running on separate machines that TLS is required.

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

Re. Proposal 1

I like Proposal 1 because it allows ES to be the source of truth about whether it has TLS enabled on the transport layer. I wonder if we could use the Nodes Info API to retrieve this info. It appears to return this information, but we'd need to confirm that it's a reliable source:

GET /_nodes/settings

...snip...

"security": {
            "authc": {
              "token": {
                "enabled": "true"
              },
              "reserved_realm": {
                "enabled": "false"
              },
              "realms": {
                "file": {
                  "found": {
                    "order": "0"
                  }
                },
                "native": {
                  "native": {
                    "order": "1"
                  }
                }
              },
              "anonymous": {
                "username": "anonymous",
                "authz_exception": "false",
                "roles": "anonymous"
              }
            },
            "enabled": "true",
            "http": {
              "ssl": {
                "enabled": "true"
              }
            },
            "transport": {
              "ssl": {
                "enabled": "true"
              }
            }
          }
        },

The downside to Proposal 1 is that we're trusting the response from an unauthenticated connection, so it's possible for someone with a MitM position to trick Kibana into believing that they're talking to ES, and that ES is running in "dev mode".

Re. Proposal 2

If Kibana is communicating with Elasticsearch using a hostname other than localhost or 127.0.0.1 we could use this as an indication that Kibana is in production mode.

This might be a workable heuristic, but it's also possible that Kibana is simply connecting to a dedicated coordinating node on the same host. If that's the case, then Kibana will believe that it's running in dev mode, even though it's possibly connected to a prod ES cluster.

Proposal 3?

Is there a reason that we want to selectively enforce https for Kibana, but not for the rest of the HTTP clients? What would happen if ES just required https everywhere if the token service was enabled?

I certainly don't want to complicate the authc flow any, but if we didn't want blanket https everywhere, I wonder if we could enforce this at authentication time...perhaps the internal kibana user could indicate to ES that it requires use of the token service as part of its request, and ES can make the decision as to whether the request is allowed or not, depending on the state of http and dev/prod mode.

[kobelb]

This might be a workable heuristic, but it's also possible that Kibana is simply connecting to a dedicated coordinating node on the same host. If that's the case, then Kibana will believe that it's running in dev mode, even though it's possibly connected to a prod ES cluster.

As long as the coordinating node is using TLS for its transport communication, all traffic which goes over the network will end up being encrypted, which is fine in this situation. It's potentially problematic if we tried to use this "production mode" detection for other purposes.

Is there a reason that we want to selectively enforce https for Kibana, but not for the rest of the HTTP clients? What would happen if ES just required https everywhere if the token service was enabled?

This is the long-term goal. Ideally, as soon as security is enabled in Elasticsearch, they would require that all HTTP communication be over TLS. However, having to synchronize this behavior across all clients becomes complicated. We were hoping to make a step towards this by allowing the clients themselves to do the enforcement instead of Elasticsearch.

[legrego]

As long as the coordinating node is using TLS for its transport communication, all traffic which goes over the network will end up being encrypted, which is fine in this situation. It's potentially problematic if we tried to use this "production mode" detection for other purposes.

That's a fair point. So maybe proposal 2 would be the way to go then

[jportner]

+1 for Proposal 2. It's more restrictive, but simpler and leaves less room for error.

Just making sure I understand this correctly, this does mean that an instance of Kibana connecting to Elasticsearch running on the same machine -- and communicating over HTTP via localhost -- still won't be able to use the restricted APIs, correct? If so, that would mean that Kibana would still need to use the "basic" auth provider by default when running locally, yes?

[kobelb]

Just making sure I understand this correctly, this does mean that an instance of Kibana connecting to Elasticsearch running on the same machine -- and communicating over HTTP via localhost -- still won't be able to use the restricted APIs, correct? If so, that would mean that Kibana would still need to use the "basic" auth provider by default when running locally, yes?

That's a good point. As long as the instance Kibana was communicating with was in dev-mode, this would be fine. But in the situation where the local instance is in production mode, as far as I understand this call would fail without changes on the Elasticsearch side. @elastic/es-security would you mind confirming this?

[tvernum]

As it currently stands, it is not possible to enable the token service (in prod mode) unless xpack.security.http.ssl.enabled is true.

We are considering other options, including supporting both http and https on the same node, in which case we will need to change this implemention to enable the token service automatically, but only allow token creation/auth over https. We could decide to treat connections from localhost as equivalent to https.

If we don't do a dual http/https stack, then the other option is to allow the token service if the http server is bound to a local network interface. That would mean the ES node would need to be dedicated to kibana (or have a reverse proxy on the box), but I think it's possible to have the token service enabled on 1 node, but not others (it wasn't in earlier versions, but I think we can now).