Skip to content

Commit 5d5d14a

Browse files
eedugoneedugon
committed
content simplified
1 parent b3fca26 commit 5d5d14a

File tree

2 files changed

+13
-49
lines changed

2 files changed

+13
-49
lines changed

‎deploy-manage/remote-clusters/connection-modes.md‎

Lines changed: 12 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,7 @@
11
---
22
navigation_title: Connection modes
33
applies_to:
4-
deployment:
5-
ece: ga
6-
ess: ga
7-
eck: ga
8-
self: ga
4+
stack: ga
95
serverless: unavailable
106
products:
117
- id: elasticsearch
@@ -14,55 +10,35 @@ products:
1410

1511
When you configure a remote cluster, the local cluster needs a way to connect to the nodes of the remote cluster. {{es}} supports two connection modes to handle different network architectures:
1612

17-
- **Sniff mode**: The local cluster discovers the remote cluster’s gateway nodes and connects to them directly.
18-
- **Proxy mode**: The local cluster connects through a reverse proxy or load balancer, which forwards traffic to the appropriate nodes in the remote cluster.
13+
- **Proxy mode**: The local cluster connects through a reverse proxy or load balancer, which forwards traffic to the appropriate nodes in the remote cluster. You can configure this mode using either the {{kib}} UI or the {{es}} API.
14+
- **Sniff mode**: The local cluster discovers the remote cluster’s gateway nodes and connects to them directly. This mode can only be configured using the {{es}} API.
1915

2016
::::{note}
2117
Connection modes work independently of [security models](./security-models.md). Both connection modes are compatible with either security model.
2218
::::
2319

24-
The choice between sniff and proxy mode depends on your network architecture and deployment type.
20+
The choice between proxy and sniff mode depends on your network architecture and deployment type.
2521

2622
- **Self-managed clusters:** If direct connections on the publish addresses between {{es}} nodes in both clusters are possible, you can use sniff mode. If direct connectivity is difficult to implement—for example, when clusters are separated by NAT, firewalls, or containerized environments—you can place a reverse proxy or load balancer in front of the remote cluster and use proxy mode instead.
2723

2824
- **Managed environments ({{ece}}, {{ech}}, {{eck}}):** Direct node-to-node connectivity is generally not feasible, so these deployments always rely on the proxy connection mode.
2925

30-
3126
The following sections describe each method in more detail.
3227

33-
## Sniff mode
34-
```{applies_to}
35-
deployment:
36-
self: ga
37-
```
38-
39-
In sniff mode, a cluster alias is registered with a name of your choosing and a list of addresses of *seed* nodes specified with the `cluster.remote.<cluster_alias>.seeds` setting. When you register a remote cluster using sniff mode, {{es}} retrieves from one of the seed nodes the addresses of up to three *gateway nodes*. Each `remote_cluster_client` node in the local {{es}} cluster then opens several TCP connections to the publish addresses of the gateway nodes. This mode therefore requires that the gateway nodes' publish addresses are accessible to nodes in the local cluster.
40-
41-
Sniff mode is the default connection mode when adding a remote cluster. See [Sniff mode remote cluster settings](remote-clusters-settings.md#remote-cluster-sniff-settings) for more information about configuring sniff mode.
42-
43-
::::{note}
44-
Sniff mode is not supported in {{ech}} and {{ece}} deployments. In {{eck}}, sniff mode is not recommended due to its complexity. In these three cases, use proxy mode instead.
45-
::::
46-
47-
4828
## Proxy mode
4929

5030
In proxy mode, a cluster alias is registered with a name of your choosing and the address of a TCP (layer 4) reverse proxy specified with the `cluster.remote.<cluster_alias>.proxy_address` setting. You must configure this proxy to route connections to one or more nodes of the remote cluster. The service port to forward traffic to depends on the [security model](./security-models.md) in use, as each model uses a different service port.
5131

5232
When you register a remote cluster using proxy mode, {{es}} opens several TCP connections to the proxy address and uses these connections to communicate with the remote cluster. In proxy mode, {{es}} disregards the publish addresses of the remote cluster nodes, which means that the publish addresses of the remote cluster nodes do not need to be accessible to the local cluster.
5333

54-
Proxy mode is not the default connection mode, so you must set `cluster.remote.<cluster_alias>.mode: proxy` to use it. See [Proxy mode remote cluster settings](remote-clusters-settings.md#remote-cluster-proxy-settings) for more information about configuring proxy mode.
34+
Proxy mode is not the default connection mode when adding remotes using the {{es}} API, so you must set `cluster.remote.<cluster_alias>.mode: proxy` to use it. Refer to [Proxy mode remote cluster settings](remote-clusters-settings.md#remote-cluster-proxy-settings) for more information about configuring proxy mode.
5535

56-
## Connection mode comparison
36+
::::{note}
37+
Remote clusters configured through **{{kib}}** support only proxy mode. You can’t select a connection mode or configure sniff mode from the UI.
38+
::::
5739

58-
The following table summarizes the key differences between sniff and proxy mode to help you choose the most suitable option for your deployment.
40+
## Sniff mode
41+
42+
In sniff mode, a cluster alias is registered with a name of your choosing and a list of addresses of *seed* nodes specified with the `cluster.remote.<cluster_alias>.seeds` setting. When you register a remote cluster using sniff mode, {{es}} retrieves from one of the seed nodes the addresses of up to three *gateway nodes*. Each `remote_cluster_client` node in the local {{es}} cluster then opens several TCP connections to the publish addresses of the gateway nodes. This mode therefore requires that the gateway nodes' publish addresses are accessible to nodes in the local cluster.
5943

60-
| Aspect | Sniff mode | Proxy mode |
61-
|-------------------------|--------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
62-
| **Default when adding a remote** | Yes | No (must be explicitly configured) |
63-
| **Recommended deployment types** | Self-managed | Self-managed, {{ech}}, {{ece}}, and {{eck}} |
64-
| **How it connects** | Local cluster connects directly to remote node addresses, discovered from the configured seeds | Local cluster connects to a single configured address. The reverse proxy or load balancer forwards traffic to remote nodes. |
65-
| **Node discovery** | Dynamic: local cluster discovers remote gateway nodes through the seed list | None: all traffic goes through the reverse proxy |
66-
| **Network requirements**| Local cluster must be able to reach the remote cluster’s gateway node publish addresses | Only the proxy address must be reachable; no need for local cluster to connect directly to remote nodes |
67-
| **Configuration** | Configure remote seeds (`cluster.remote.<alias>.seeds`) | Configure proxy address (`cluster.remote.<alias>.proxy_address`) and set mode to `proxy` |
68-
| **Use cases** | Clusters with direct network reachability between nodes (e.g., same VPC or peered networks) | Clusters separated by firewalls, NAT, or when exposing only a single ingress point is required |
44+
Sniff mode is the default connection mode when adding a remote cluster through the {{es}} API. Refer to [Sniff mode remote cluster settings](remote-clusters-settings.md#remote-cluster-sniff-settings) for more information about configuring sniff mode.

‎deploy-manage/remote-clusters/security-models.md‎

Lines changed: 1 addition & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Remote cluster security models determine how authentication and authorization wo
1212

1313
TLS certificate–based authentication is now deprecated, and users are encouraged to migrate to the API key–based model.
1414

15-
The following sections describe both models in detail and highlight their key differences.
15+
The following sections describe each model in more detail.
1616

1717
::::{tip}
1818
Security models work independently of [connection modes](./connection-modes.md). Both security models are compatible with either connection mode.
@@ -68,15 +68,3 @@ The local cluster uses the [transport interface](elasticsearch://reference/elast
6868
### Setup
6969

7070
Refer to [Remote cluster setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.
71-
72-
### Security models: comparison
73-
74-
| Aspect | API key–based | TLS certificate–based |
75-
|---------------------|-------------------------------------------------------------------------------|------------------------------------------------|
76-
| **Status** | Recommended | Deprecated |
77-
| **Service endpoint**| Uses a dedicated remote-cluster-server service endpoint | Uses the default transport interface |
78-
| **Default port** | 9443 | 9300 in self-managed, 9400 in {{ech}} or {{ece}} |
79-
| **Authentication** | Client authenticates with an API key and validates the server’s certificate | Requires mutual TLS (both client and server present and validate certificates) |
80-
| **Authorization** | Flexible: privileges can be scoped in the API key and combined with roles on the local cluster; supports fine-grained authorization | Rigid: roles must exist on the remote cluster with exact name matching; all authorization defined remotely |
81-
| **Credential management** | API keys can be created with expiration and revoked without PKI changes | Requires certificate issuance, distribution, and rotation across clusters |
82-

0 commit comments

Comments
 (0)