ECH/ECK remote clusters doc is incorrect for trust.yml

[eedugon]

Preview:

• Remote clusters between Elastic Cloud Hosted and ECK

Summary of changes:

• Procedure updated to configure trust on ECH and ECK sides.
• Step to modify trust.yml added due to being invalid as it is (whenever this is solved in cloud UI we should change this doc).
• Yaml example updated, it had multiple bugs (thanks @naemono for highlighting that out).

Fixes #1378
Relates to private cloud issue https://github.com/elastic/cloud/issues/141360
Closes #1378

[jeanfabrice]

I think it is confusing to let the customer to enter a value, <kubernetes-namespace>.es.local, and have it corrected afterwards (because of the issue with the wizard) in the trust.yml file with another value *.node.<cluster-name>.<kubernetes-namespace>.es.local, rather than:

• not selecting trust clusters whose CN follow the Elastic pattern so that no misleading value is added to the trust.yml file,
• later on, after downloading the trust.yml file, add the definitive correct value (*.node.<cluster-name>.<kubernetes-namespace>.es.local).

Both solutions are ok that said. The proposed solution has the advantage to be easier to amend once the wizard has been fix

[eedugon]

@jeanfabrice , thanks! I think your proposal would simplify the process also, so let me apply a few changes and share them with you.

Update: I have a concern of your proposal:

• From the ECK deployment point of view all is perfect, and your suggestion of not selecting anything in the Select Trusted clusters section of the UI should be OK as long as we add the ECK details to the generated trust.yml later on.

But what about from ECH deployment point of view? would ECH trust the external / self-managed (ECK) cluster providing the CA only and leaving that section empty?

@naemono , would you please help us to determine if that part of the section can be left empty or if it's better to provide a Scope ID and then fix the generated trust.yml?

cc: @pebrc

[eedugon]

@jeanfabrice : As mentioned in private, your proposal won't work, as ECH needs the scope ID to be defined, as it was mentioned in the original doc. The why I don't know, but definitely ECH configures something that properly trusts the certificate coming from ECK when following the procedure.

So I'm leaving the procedure as it is, as I have fully tested it a few times and remote cluster functionality works fine in both directions.

In summary: The select trusted clusters section cannot be left empty

[github-actions]

🔍 Preview links for changed docs:

• deploy-manage/remote-clusters/ec-enable-ccs-for-eck.md

🔔 The preview site may take up to 3 minutes to finish building. These links will become live once it completes.

[eedugon]

@shainaraskas : I'm pinging you for reviewing. Nothing urgent.

This PR fixes a bug that we had in the original procedure.

Anyway we should soon add to this document the procedure using API Keys for this use case (as that's feasible now but still not documented). But that should be done at a later stage.

@pebrc : Feel free to give your thoughts, the procedure has been tested using the exact yamls provided in the doc and all works fine.

[shainaraskas]

really nice. nitpicks only

[shainaraskas]

nitpick: an intro sentence before a procedure is nice

[eedugon]

@shainaraskas : would you do a final review here? I've applied the suggestions you mentioned:

• Moving edit trust.yml to its own heading (I added a short introductory text).
• Added short introductions in the other headings.

[shainaraskas]

looks good to me