[DOCS] Add impact sections to security 8.0 breaking changes #56439
Conversation
jrodewig
added
>docs
|
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.
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.enabledto 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.
The comment above for transport.ssl.enabled applies here too.
Co-authored-by: Tim Vernum <tim@adjective.org>
|
Thanks for the corrections and explanation @tvernum. I've updated the changes to address. |
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?