Fix formating & add needed config for xpack.security.remote_cluster_s…

[SimonKoetting]

Summary

Fix formating & add needed configs for xpack.security.remote_cluster_server.ssl setting when using own certificates

Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?

• Yes
• No

[github-actions]

Elastic Docs AI PR menu

Check the box to run an AI review for this pull request.

• Review docs changes (docs-review). Status: not started.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

[github-actions]

🔍 Preview links for changed docs

• deploy-manage/security/k8s-transport-settings.md

[github-actions]

Elastic Docs Style Checker (Vale)

Summary: 1 suggestion found

💡 Suggestions (1): Optional style improvements. Apply when helpful.

File	Line	Rule	Message
deploy-manage/security/k8s-transport-settings.md	126	Elastic.WordChoice	Consider using 'deactivates, deselects, hides, turns off, makes unavailable' instead of 'Disables', unless the term is in the UI.

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[eedugon]

Great catch @SimonKoetting , thanks for sharing this.

Now that the footnote 3 is getting bigger I'd like to convert it to a note and probably provide some extra background and links for the remote_cluster_client to be better addressed.

Would you mind if I apply a commit to your PR and we can review it together before merging? Or do you prefer if we merge this change and then I create a follow-up PR to update the format of the content a bit?

I'd like to make sure that the reader understands that the remote_cluster_server is used in the destination cluster when configuring Remote Clusters through API key-based authentication.

[SimonKoetting]

@eedugon sound good to me, feel free to add the commit to this PR so we can address this right away :)

[eedugon]

@SimonKoetting , I have commited directly to your branch with a format change, and also included the opposite link: If a user is configuring remote cluster server interface and they are already using certificates created by a third-party tool they should also follow this guidance.

For the example I'm not sure if the current dropdown is a good choice or if we could move the example of RCS+third-party certs to its own sub-section at the end of the document.

@shainaraskas , would you please share your thoughts here? it's a very small PR that covers a small gap that we had in our docs between RCS 2.0 (api key based auth) and ECK not handling transport certs automatically.

The options for the content in deploy-manage/security/k8s-transport-settings.md are:

• Add the needed settings in a note without providing the entire example.
• Add the entire example in a dropdown (current version)
• Add the entire example in its own sub-section at the end.

[SimonKoetting]

Besides this little nit, the changes look good to me. 👍 @eedugon

[eedugon]

@SimonKoetting : I've applied your suggestion and also converted the dropdown example to its own sub-section, per @yetanothertw 's feedback.

Let us know your thoughts, and thanks a lot for your patience :)

[SimonKoetting]

LGTM :) @eedugon

[yetanothertw]

Nice work! Really like that you've moved the dropdown into its own section for maximum clarity. 🪴

I've left a minor (not a blocker) comment re the elasticsearch version in your example config manifest, see what you think.

[yetanothertw]

This might not even be relevant, but should we try to use 9.something as this is the 9.X docset?

[eedugon]

yeah, I'm planning to address all ECK examples in a different PR, to use {{version.stack}} where applicable.
For the moment I've left the example as a copy&paste of the previous example but with the extra needed settings.

[shainaraskas]

@eedugon sorry I missed this. I like the new section. it's a good alternative to the big footnote