Enroll additional nodes to cluster #77292
Conversation
This introduces a new named argument (--enrollment-token) that can be passed to the elasticsearch executables when starting a node. It takes an Enrollment Token as a value and using the information in it, it Elasticsearch will attempt to - Communicate with an existing node of the cluster - Receive necessary key/certificate material - Persist said material and configuration before the node is actually started. This can only happen if this is the first time the current node starts and if it doesn't have any explicit security related configuration defined.
jkakavas
added
>enhancement
:Delivery/Packaging
jkakavas
requested review from
rjernst,
tvernum,
pugnascotia and
BigPandaToo
elasticmachine
added
Team:Delivery
|
Pinging @elastic/es-delivery (Team:Delivery) |
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
|
Pinging @elastic/es-security (Team:Security) |
|
Hi @jkakavas, I've created a changelog YAML for you. |
| @@ -4,9 +4,11 @@ | |||
| * 2.0; you may not use this file except in compliance with the Elastic License | |||
| * 2.0. | |||
| */ | |||
| package org.elasticsearch.xpack.security.tool; | |||
| package org.elasticsearch.xpack.core.security; | |||
There was a problem hiding this comment.
I moved CommandLineHttpClient, HttpResponse and EnrollmentToken to core so that I can use them in EnrollNodeToCluster without needing to add a dependency to the security plugin in security:cli. The issue with that would be that I'd have a dependency conflict for Guava (30-1 as a jimfs dependency in security:cli vs 19 in security) I couldn't think of a way to solve this dependency issue, but more than happy to get suggestions and I'll move this back to the security plugin
...k/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/CommandLineHttpClient.java
Show resolved
Hide resolved
| /** | ||
| * Configures a node to join an existing cluster with security features enabled. | ||
| */ | ||
| public class EnrollNodeToCluster extends KeyStoreAwareCommand { |
There was a problem hiding this comment.
This class shares a lot of code with ConfigInitialNode from #77291. As we were working on these two PRs simultaneously is was impractical to stay in sync and deal with all merge conflicts. Additionally, the error handling is different in certain cases. When both this and #77291 are merged, there will be a follow-up PR ASAP to move anything we can in a base class and remove code duplication
distribution/src/bin/elasticsearch
Outdated
| @@ -45,6 +49,14 @@ then | |||
| fi | |||
| fi | |||
|
|
|||
| if [[ $ENROLL_TO_CLUSTER = true ]]; then | |||
There was a problem hiding this comment.
The idea here is that this part runs only when an explicit flag is passed by the user. We will attempt to do our auto-configuration of TLS based on the enrollment process and only if everything went well will the node start with that configuration. If anything fails, we roll-back the configuration and fail with an error message.
libs/ssl-config/src/main/java/org/elasticsearch/common/ssl/PemUtils.java
Outdated
Show resolved
Hide resolved
...k/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/CommandLineHttpClient.java
Show resolved
Hide resolved
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/EnrollmentToken.java
Outdated
Show resolved
Hide resolved
Both work for me as it doesn't matter for all current intents and purposes. I'll change to chain[1] and revisit if/when we want to handle a more generic enrollment use case |
…oin an existing cluster
|
@rjernst , @pugnascotia , given that we are not merging #77231 now, it wouldn't make much sense to introduce this functionality as a parameter to the |
The functionality to enroll a new node to a cluster was introduced in elastic#77292 as a CLI tool. This change brings forward two additions: - It allows to trigger the enrollment functionality on startup of elasticsearch via a named argument that can be passed to the es startup script (--enrollment-token) so that the users that want to do this do not need to run two commands instead of one. - It adds a `-f, --force` flag to the standalone CLI version of this which bypasses the checks for whether there are data in the current node or whether security related features are already configured. The primary use case for this flag is enrolling new nodes in packaged installations. There we auto-configure each installation as a first node of a cluster by default because we don't have a user-friendly and generic way to allow the user decide on installation time. Thus, we want to allow users to easily reconfigure the node to enroll to an existing cluster without requiring many manual steps.
The functionality to enroll a new node to a cluster was introduced in #77292 as a CLI tool. This change replaces this CLI tool with the option to trigger the enrollment functionality on startup of elasticsearch via a named argument that can be passed to the elasticsearch startup script (--enrollment-token) so that the users that want to enroll a node to a cluster can do this with one command instead of two. In a followup PR we are introducing a CLI tool version of this functionality, that can be used to reconfigure packaged installations.
This introduces a new CLI tool
elasticsearch-enroll-node.It takes an Enrollment Token as a parameter and using the
information in it, it attempts to
This tool needs to be run before the first time the current
node starts and if it doesn't have any explicit security
related configuration already defined.