-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[DOCS] Add impact sections to security 8.0 breaking changes #56439
[DOCS] Add impact sections to security 8.0 breaking changes #56439
Conversation
Pinging @elastic/es-docs (:Docs) |
Pinging @elastic/es-security (:Security/Security) |
If using `xpack.security.transport.ssl` settings, ensure | ||
`xpack.security.transport.ssl.enabled` is set as `true`. Not specifying | ||
`xpack.security.transport.ssl.enabled` as `true` in `elasticsearch.yml` will | ||
result in an error on startup. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't quite right. You are fee to set xpack.security.transport.ssl.enabled
to true
or false
, you just can't leave it unspecified if you have set other any xpack.security.transport.ssl.*
settings.
This setting defaults to false
if unspecified. The 7.x (and earlier) behaviour is that nodes that had a xpack.security.transport.ssl
setting (e.g. xpack.security.transport.ssl.certificate
) but did not explicitly set ssl.enabled
, would not have SSL enabled.
That was confusing because on first inspection it would look like SSL was configured, but since it was not explicitly enabled, it didn't actually do anything.
For people in that situation, the no impact upgrade would be to explicitly set ssl.enabled
to false
to acknowledge that even though they've configured SSL they don't want it to be on.
The "right fix" is for them to work out why they have ssl.*
settings in their yml but don't have SSL enabled. Is that intentional?
- If so, remove the
ssl.*
settings or setssl.enabled
to false. - Otherwise, maybe they want to turn on ssl (
ssl.enabled: true
), but that's a bigger change & we can't really walk them through it here (but we could point to the relevant docs).
I don't really know how to explain that well in the breaking changes doc. How much detail do we want to go to?
But I don't think we can recommend people just set it to true
because that would cause a noticeable change to their cluster - it would turn on SSL when it was previously disabled - and they need to at least think through how they want to coordinate that change across their nodes (for transport.ssl
) or with clients (for http.ssl
)
`xpack.security.http.ssl.enabled` is set as `true`. Not specifying | ||
`xpack.security.transport.ssl.enabled` as `true` in `elasticsearch.yml` will | ||
result in an error on startup. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment above for transport.ssl.enabled
applies here too.
Co-authored-by: Tim Vernum <[email protected]>
Thanks for the corrections and explanation @tvernum. I've updated the changes to address. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Thanks.
Adds impact sections to the 8.0 breaking changes for security.
Relates to #55629 and #53229
@tvernum This is intended largely as a formatting update. However, I want to ensure I didn't unintentionally lose any context or introduce errors here. Can you review at your convenience?