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]

Suggested change

	## Establish trust between two clusters [ec_establish_trust_between_two_clusters]
	## Establish trust between the two clusters [ec_establish_trust_between_two_clusters]

[shainaraskas]

Suggested change

	2. Select **Certificates** as authentication mechanism and click **Next**.
	2. Select **Certificates** as the authentication mechanism and click **Next**.

[shainaraskas]

nitpick: an intro sentence before a procedure is nice

[shainaraskas]

avoid sentence fragments like this

Suggested change

	Replace the line corresponding to the `Scope ID` you entered when configuring trust in the ECH deployment:
	```sh
	"*.node.*.cluster.<kubernetes-namespace>.es.local.account"
	```
	with the correct subject name for your ECK cluster, using the following pattern:
	```sh
	"*.node.<cluster-name>.<kubernetes-namespace>.es.local"
	```
	Replace the line corresponding to the `Scope ID` you entered when configuring trust in the ECH deployment:
	```sh
	"*.node.*.cluster.<kubernetes-namespace>.es.local.account"
	```
	Replace it with the correct subject name for your ECK cluster. The new subject name should use the following pattern:
	```sh
	"*.node.<cluster-name>.<kubernetes-namespace>.es.local"
	```

[shainaraskas]

Suggested change

	If you don’t update this entry, {{es}} nodes of your ECK deployment may fail to start or join the cluster due to failed trust validation.
	If you don’t update this entry, {{es}} nodes of your ECK deployment might fail to start or join the cluster due to failed trust validation.

[shainaraskas]

Suggested change

	For example, the original downloaded file might contain:
	For example, the original downloaded file might contain the following:

[shainaraskas]

Suggested change

	For an ECK cluster named `quickstart` in the `default` namespace, the updated file should look like:
	For an ECK cluster named `quickstart` in the `default` namespace, the updated file should look like the following:

[shainaraskas]

Suggested change

	3. In the same namespace as your {{es}} cluster, upload the updated `trust.yml` file as a Kubernetes ConfigMap. For a cluster named `quickstart`, run:
	3. In the same namespace as your {{es}} cluster, upload the updated `trust.yml` file as a Kubernetes ConfigMap. For a cluster named `quickstart`, run the following command:

[shainaraskas]

Suggested change

	4. Edit the {{es}} Kubernetes resource to include the following configuration. This example assumes that the Kubernetes secret and config map created in the previous steps are named `remote-ech-ca` and `quickstart-trust-ech`, respectively:
	4. Edit the {{es}} Kubernetes resource to reference the new certificate and trust.yml file. This example assumes that the Kubernetes secret and ConfigMap created in the previous steps are named `remote-ech-ca` and `quickstart-trust-ech`, respectively:

[shainaraskas]

Suggested change

	Apply these changes to all `nodeSets` of your cluster. Updating this configuration will restart all {{es}} pods, which may take some time to complete.
	Apply these changes to all `nodeSets` of your cluster. Updating this configuration will restart all {{es}} pods, which might take some time to complete.