-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Nodes without security explicitly enabled cannot join cluster with security enabled. #31332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
>bug
:Distributed Indexing/Distributed
A catch all label for anything in the Distributed Indexing Area. Please avoid if you can.
:Security/Authentication
Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)
v6.3.0
Comments
Pinging @elastic/es-security |
Pinging @elastic/es-distributed |
jaymode
added a commit
to jaymode/elasticsearch
that referenced
this issue
Jun 14, 2018
The changes made to disable security for trial licenses unless security is explicitly enabled caused issues when a 6.3 node attempts to join a cluster that already has a production license installed. The new node starts off with a trial licenses and `xpack.security.enabled` is not set for the node, which causes the security code to skip attaching the user to the request. The existing cluster has security enabled and the lack of a user attached to the requests causes the request to be rejected. This commit changes the security code to check if the state has been recovered yet when making the decision on whether or not to attach a user. If the state has not yet been recovered, the code will attach the user to the request in case security is enabled on the cluster being joined. Closes elastic#31332
jaymode
added a commit
that referenced
this issue
Jun 19, 2018
The changes made to disable security for trial licenses unless security is explicitly enabled caused issues when a 6.3 node attempts to join a cluster that already has a production license installed. The new node starts off with a trial license and `xpack.security.enabled` is not set for the node, which causes the security code to skip attaching the user to the request. The existing cluster has security enabled and the lack of a user attached to the requests causes the request to be rejected. This commit changes the security code to check if the state has been recovered yet when making the decision on whether or not to attach a user. If the state has not yet been recovered, the code will attach the user to the request in case security is enabled on the cluster being joined. Closes #31332
jaymode
added a commit
that referenced
this issue
Jun 19, 2018
The changes made to disable security for trial licenses unless security is explicitly enabled caused issues when a 6.3 node attempts to join a cluster that already has a production license installed. The new node starts off with a trial license and `xpack.security.enabled` is not set for the node, which causes the security code to skip attaching the user to the request. The existing cluster has security enabled and the lack of a user attached to the requests causes the request to be rejected. This commit changes the security code to check if the state has been recovered yet when making the decision on whether or not to attach a user. If the state has not yet been recovered, the code will attach the user to the request in case security is enabled on the cluster being joined. Closes #31332
jaymode
added a commit
that referenced
this issue
Jun 19, 2018
The changes made to disable security for trial licenses unless security is explicitly enabled caused issues when a 6.3 node attempts to join a cluster that already has a production license installed. The new node starts off with a trial license and `xpack.security.enabled` is not set for the node, which causes the security code to skip attaching the user to the request. The existing cluster has security enabled and the lack of a user attached to the requests causes the request to be rejected. This commit changes the security code to check if the state has been recovered yet when making the decision on whether or not to attach a user. If the state has not yet been recovered, the code will attach the user to the request in case security is enabled on the cluster being joined. Closes #31332
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
>bug
:Distributed Indexing/Distributed
A catch all label for anything in the Distributed Indexing Area. Please avoid if you can.
:Security/Authentication
Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc)
v6.3.0
This seems to be caused by the change to made security disabled by default on trial licenses.
If a node does not set
xpack.security.enabled
in the config, and tries to join a cluster, it doesn't know what type of license its supposed to be using, and seems to be acting as if its on a trial license with security disabled.This means that
SecurityServerTransportInterceptor.interceptSender().AsyncSender.sendRequest()
does not intercept the request, and does not set the system-user context for outgoing requests.Since the requests do not have an authentication header attached to their context, the remote node rejects the initial handshake, and the new node cannot join.
The text was updated successfully, but these errors were encountered: