elastic / elasticsearch

Free and Open Source, Distributed, RESTful Search Engine
https://www.elastic.co/products/elasticsearch
Other
69.64k stars 24.64k forks source link

[Bug] Nodes can't be restarted in a Cluster with xpack.security.enabled: true #48912

Open Zyklop opened 4 years ago

Zyklop commented 4 years ago

Elasticsearch version (bin/elasticsearch --version): 7.2.1

Plugins installed: [analysis-phonetic]

JVM version (java -version): open jdk 11.0.4

OS version (uname -a if on a Unix-like system): Ubuntu 18.04 LTS

Description of the problem including expected versus actual behavior:

Actual behavior: When creating a Cluster with" xpack.security.enabled: true" and no "xpack.security.transport.ssl.enabled" setting each node initially starts fine. When restarting the nodes, elastic refuses to start saying that "xpack.security.transport.ssl.enabled" has to be enabled.

Expected behavior: Either the cluster works all the time in in non-TLS mode when the security is active or the nodes refuse their initail start if there are some masternodes defined.

Steps to reproduce:

  1. Setup multiple different machines
  2. Install Elasticsearch on all the machines
  3. Set "xpack.security.enabled: true" and declare some masternodes
  4. Start Elasticsearch on all the machines at the same time
  5. The cluster should now be running fine
  6. Restart the elasticsearch service on one or multiple nodes
  7. The nodes refuse to start

Provide logs (if relevant):

[1] bootstrap checks failed [1]: Transport SSL must be enabled if security is enabled on a [basic] license. Please set [xpack.security.transport.ssl.enabled] to [true] or disable security by setting [xpack.security.enabled] to [false]

elasticmachine commented 4 years ago

Pinging @elastic/es-security (:Security/Security)

tvernum commented 4 years ago

We should do a better job here, but I don't know what that would look like.

The problem is that SSL is not required on a trial license, which means that we can only enforce the bootstrap check if we know the license type, and a newly started node does not know what license the cluster will have. For maximum compatibilty, we don't enforce SSL unless/until we know which license type is in use.

If we switched to enforcing SSL on trial, that would solve this, but has impacts on users.

We could fail the node as soon as we know that it has a non-trial license but doesn't have SSL. We had code to do something like that before, but we removed it because it caused other issues. We might need to bring it back.

AronNovak commented 3 years ago

This is especially problematic as I understood that there's no way to buy a license, the only option is to use Elastic Cloud. We have a Helm Chart configured with an ingress that provides SSL, now it's impossible to upgrade the version of Elasticsearch. At the initial experiments, everything went smoothly with the HTTP auth and the ingress-provided SSL.

AronNovak commented 3 years ago

Actually it seems based on TLSLicenseBootstrapCheckTests, it has nothing to do with licensing. testBootstrapCheckFailureOnPremiumLicense expects the failure too, so the error message is highly misleading.