Skip to content
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

Tribe Node fails to start with secure settings for xpack.security #32117

Closed
tvernum opened this issue Jul 17, 2018 · 4 comments
Closed

Tribe Node fails to start with secure settings for xpack.security #32117

tvernum opened this issue Jul 17, 2018 · 4 comments
Assignees
Labels
>bug :Core/Infra/Settings Settings infrastructure and APIs :Security/Security Security issues without another label v6.3.1

Comments

@tvernum
Copy link
Contributor

tvernum commented Jul 17, 2018

If a node is configured as a tribe node, then we automatically copy each xpack.security.* setting from the root settings, to each of the tribe client settings (Security.addTribeSettings)

However, that fails if the xpack.security setting is a SecureSetting as Settings.Builder.copy cannot copy secure settings.
The error is a somewhat cryptic

Caused by: java.lang.IllegalArgumentException: source key not found in the source settings

Given Tribe is deprecated in 6.x and removed in 7, we don't want to do much here, but we don't want a situation where nodes fail to start, and the errors are unclear.

Possible solutions:

  1. Don't allow secure settings for xpack.security.* on tribe nodes. That is, in addTribeSettings fail if we find a secure setting (with a reasonable error message)
  2. Check & require that the tribe.xyz.xpack.security.* secure setting already exist in the keystore. That is if, xpack.security.transport.ssl.keystore.secure_password exists in the keystore, require that tribe.xyz.xpack.security.transport.ssl.keystore.secure_password also exist, and fail with a reasonble error message if it does not.
@tvernum tvernum added >bug :Security/Security Security issues without another label v6.3.1 labels Jul 17, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

@jaymode jaymode added the :Core/Infra/Settings Settings infrastructure and APIs label Jul 17, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@jasontedor
Copy link
Member

jasontedor commented Jul 19, 2018

We discussed this during the core/infra weekly meeting today and we have agreement that we are not going to address this issue. We feel this is justified because:

  • the tribe node is deprecated and already removed from the codebase for 7.0.0
  • it appears that configuring a tribe node in this way has not worked since the settings in question were made secure settings this doesn't qualify as regression

As such, we feel the only change here should be making the error message clearer.

rjernst added a commit to rjernst/elasticsearch that referenced this issue Jul 23, 2018
This commit adds a clear error message when tribe setup attempts to copy
a secure setting into tribe settings. This behavior has never worked,
but the previous error message was very confusing, complaining about a
source key not being found later when trying to read the setting.

closes elastic#32117
rjernst added a commit that referenced this issue Jul 24, 2018
This commit adds a clear error message when tribe setup attempts to copy
a secure setting into tribe settings. This behavior has never worked,
but the previous error message was very confusing, complaining about a
source key not being found later when trying to read the setting.

closes #32117
@rjernst
Copy link
Member

rjernst commented Oct 25, 2018

The error message was made more clear in #32298, thus I am closing this issue per above agreement.

@rjernst rjernst closed this as completed Oct 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Core/Infra/Settings Settings infrastructure and APIs :Security/Security Security issues without another label v6.3.1
Projects
None yet
Development

No branches or pull requests

5 participants