ECE and ECH to ECK remote clusters setup updated for API keys #3849
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🔍 Preview links for changed docs |
shainaraskas
approved these changes
Nov 10, 2025
Collaborator
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
structurally lgtm. left some minor notes :)
Comment on lines
+3
to
+4
| ```sh | ||
| quickstart-es-remote-cluster ClusterIP None <none> 9443/TCP 4h13m |
Collaborator
There was a problem hiding this comment.
I don't see a lot of value in this code snippet. would you consider removing it, or do you think it serves a specific purpose?
| quickstart-es-remote-cluster ClusterIP None <none> 9443/TCP 4h13m | ||
| ``` | ||
|
|
||
| To allow other clusters running outside your Kubernetes environment to connect, you must expose this service externally. As of ECK {{version.eck}}, you cannot customize the service that ECK generates for the remote cluster interface, but you can create your own `LoadBalancer` service, `Ingress` object, or use another method available in your environment. |
Collaborator
There was a problem hiding this comment.
do we need to specify "as of eck 3.2"? if this ever changes that change will be reflected here
| --port=9443 --target-port=9443 | ||
| ``` | ||
|
|
||
| 1. On cloud providers which support external load balancers, setting the type to LoadBalancer provisions a load balancer for your service. Alternatively, expose the service `<cluster-name>-es-remote-cluster` through one of the Kubernetes Ingress controllers that support TCP services. |
Collaborator
There was a problem hiding this comment.
Suggested change
| 1. On cloud providers which support external load balancers, setting the type to LoadBalancer provisions a load balancer for your service. Alternatively, expose the service `<cluster-name>-es-remote-cluster` through one of the Kubernetes Ingress controllers that support TCP services. | |
| 1. On cloud providers that support external load balancers, setting the type to `LoadBalancer` provisions a load balancer for your service. Alternatively, expose the service `<cluster-name>-es-remote-cluster` through one of the Kubernetes Ingress controllers that support TCP services. |
|
|
||
| * **{{es}} TLS termination** | ||
|
|
||
| If the connection reaches the {{es}} Pods without intermediate TLS termination, the {{es}} nodes present their transport certificates managed by ECK. The local cluster must therefore trust these certificates by including the ECK-managed transport CA, which you can retrieve in the next section. |
Collaborator
There was a problem hiding this comment.
Suggested change
| If the connection reaches the {{es}} Pods without intermediate TLS termination, the {{es}} nodes present their transport certificates managed by ECK. The local cluster must therefore trust these certificates by including the ECK-managed transport CA, which you can retrieve in the next section. | |
| If the connection reaches the {{es}} Pods without intermediate TLS termination, the {{es}} nodes present transport certificates managed by ECK. The local cluster must therefore trust these certificates by including the ECK-managed transport CA, which you can retrieve in the next section. |
| 1. On cloud providers which support external load balancers, setting the type to LoadBalancer provisions a load balancer for your service. Alternatively, expose the service `<cluster-name>-es-remote-cluster` through one of the Kubernetes Ingress controllers that support TCP services. | ||
|
|
||
|
|
||
| :::{admonition} About exposing the service and TLS certificates |
Collaborator
There was a problem hiding this comment.
didn't think too deeply about this, but does this snippet belong here, or would it make more sense in the Retrieve the ECK-managed CA certificate of the remote cluster server section (because that's what this information is relevant to)? you kind of have to restate some of your explanations the way you have the content organized.
|
|
||
| If the external connections reach the {{es}} Pods on port `9443` without any intermediate TLS termination, you must retrieve this CA, as it will be required in the local cluster configuration to establish trust. | ||
|
|
||
| For example, to save the transport CA certificate of a cluster named `quickstart` into a local file, run: |
Collaborator
There was a problem hiding this comment.
Suggested change
| For example, to save the transport CA certificate of a cluster named `quickstart` into a local file, run: | |
| For example, to save the transport CA certificate of a cluster named `quickstart` into a local file, run the following command: |
| -o go-template='{{index .data "ca.crt" | base64decode}}' > eck_transport_ca.crt | ||
| ``` | ||
|
|
||
| You can verify that the file contains a valid CA certificate by running: |
Collaborator
There was a problem hiding this comment.
this is less fragmenty (localizes better)
Suggested change
| You can verify that the file contains a valid CA certificate by running: | |
| You can verify that the file contains a valid CA certificate by running the following command: |
| ::::{important} | ||
| ECK-managed CA certificates are automatically rotated after one year by default, but you can [configure](/deploy-manage/deploy/cloud-on-k8s/configure-eck.md) a different validity period. | ||
|
|
||
| Ensure that this CA is updated in all environments where it's used after rotation to preserve trust. |
Collaborator
There was a problem hiding this comment.
maybe? generally better to start a sentence with its context ("when x") before diving into the action. helps people skim.
Suggested change
| Ensure that this CA is updated in all environments where it's used after rotation to preserve trust. | |
| When the CA certificate is rotated, ensure that this CA is updated in all environments where it's used to preserve trust. |
|
|
||
| #### Establish trust in the {{ece}} cluster [ece_establish_trust_in_the_elastic_cloud_enterprise_cluster] | ||
|
|
||
| 1. Save the ECK CA certificate to a file. For a cluster named `quickstart`, run: |
Collaborator
There was a problem hiding this comment.
this is old - not sure if you were planning on changing it - but this pattern of linking deeply into the other tutorial is not ideal. I realize this is the deprecated approach so it's not as important to tidy up, but just stating this for the record.
Comment on lines
+3
to
+9
| ::::{note} | ||
| When configuring the remote cluster connection: | ||
|
|
||
| * **Remote address**: Use the FQDN or IP address of the LoadBalancer service, or similar resource, you created to expose the remote cluster server interface (for API key-based authentication) or the transport interface (for TLS certificate-based authentication). | ||
|
|
||
| * **TLS server name**: You can try leaving this field empty first. If the connection fails, and your environment is presenting the ECK-managed certificates during the TLS handshake, use `<cluster-name>-es-remote-cluster.<namespace>.svc` as the server name. For example, for a cluster named `quickstart` in the `default` namespace, use `quickstart-es-remote-cluster.default.svc`. | ||
| :::: |
Collaborator
There was a problem hiding this comment.
I don't think this should be in a note. it's basics about the variables.
| type: LoadBalancer <1> | ||
| ``` | ||
| 1. On cloud providers which support external load balancers, setting the type field to LoadBalancer provisions a load balancer for your service. Alternatively, expose the service `<cluster-name>-es-transport` through one of the Kubernetes Ingress controllers that support TCP services. |
Collaborator
There was a problem hiding this comment.
Suggested change
| 1. On cloud providers which support external load balancers, setting the type field to LoadBalancer provisions a load balancer for your service. Alternatively, expose the service `<cluster-name>-es-transport` through one of the Kubernetes Ingress controllers that support TCP services. | |
| 1. On cloud providers which support external load balancers, setting the type field to `LoadBalancer` provisions a load balancer for your service. Alternatively, expose the service `<cluster-name>-es-transport` through one of the Kubernetes Ingress controllers that support TCP services. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces the Remote Clusters -> API Key security model configuration for the following use cases:
TLS certificate-based authentication method (deprecated) has been left untouched, except of a minor step to expose the transport service of the destination ECK cluster, which was missing.
The procedure has been fully tested.
All based on snippets as the content of both pages is almost identital.
Relates to #1645
In future PRs we will handle the opposite use cases: ECK --> external clusters (self-managed, ECH/ECE, etc) setup.
Reviewing requests --> I'd like first a review from style and writing point of view and afterward we'll request a review from ECK devs in case they want to tweak or change anything.