You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: deploy-manage/remote-clusters.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,7 +34,7 @@ You can learn more in the following documents:
34
34
-[Connection modes](./remote-clusters/connection-modes.md): Sniff mode (direct connections to {{es}} nodes) or proxy mode (connections through a reverse proxy or load balancer endpoint).
35
35
36
36
::::{note}
37
-
In managed or orchestrated environments, such as {{ech}}, {{ece}}, and {{eck}}, you can select the security model, but the connection mode is effectively limited to *proxy*, as sniff mode requires {{es}} nodes publish addresses to be directly reachable across clusters, which is generally not practical in containerized deployments.
37
+
In managed or orchestrated environments, such as {{ech}}, {{ece}}, and {{eck}}, you can select the security model, but the connection mode is effectively limited to *proxy*. This is because sniff mode requires {{es}} nodes publish addresses to be directly reachable across clusters, which is generally not practical in containerized deployments.
Copy file name to clipboardExpand all lines: deploy-manage/remote-clusters/connection-modes.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ applies_to:
10
10
products:
11
11
- id: elasticsearch
12
12
---
13
-
# Remote clusters connection modes
13
+
# Remote cluster connection modes
14
14
15
15
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:
16
16
@@ -23,7 +23,7 @@ Connection modes work independently of [security models](./security-models.md).
23
23
24
24
The choice between sniff and proxy mode depends on your network architecture and deployment type.
25
25
26
-
-**Self-managed environments:** 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.
26
+
-**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.
27
27
28
28
-**Managed environments ({{ece}}, {{ech}}, {{eck}}):** Direct node-to-node connectivity is generally not feasible, so these deployments always rely on the proxy connection mode.
29
29
@@ -41,27 +41,27 @@ In sniff mode, a cluster alias is registered with a name of your choosing and a
41
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
42
43
43
::::{note}
44
-
The sniff mode is not supported in {{ech}} and {{ece}} deployments, and it's not recommended in {{eck}}due to its complexity. Use proxy mode instead.
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
45
::::
46
46
47
47
48
48
## Proxy mode
49
49
50
50
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.
51
51
52
-
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.
52
+
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.
53
53
54
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.
55
55
56
-
## Connection modes: comparison
56
+
## Connection mode comparison
57
57
58
58
The following table summarizes the key differences between sniff and proxy mode to help you choose the most suitable option for your deployment.
|**How it connects**| Local cluster connects directly to remote nodes 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 |
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
65
|**Node discovery**| Dynamic: local cluster discovers remote gateway nodes through the seed list | None: all traffic goes through the reverse proxy |
66
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
67
|**Configuration**| Configure remote seeds (`cluster.remote.<alias>.seeds`) | Configure proxy address (`cluster.remote.<alias>.proxy_address`) and set mode to `proxy`|
Copy file name to clipboardExpand all lines: deploy-manage/remote-clusters/security-models.md
+10-14Lines changed: 10 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,54 +1,50 @@
1
1
---
2
2
navigation_title: Security models
3
3
applies_to:
4
-
deployment:
5
-
ece: ga
6
-
ess: ga
7
-
eck: ga
8
-
self: ga
4
+
stack: ga
9
5
serverless: unavailable
10
6
products:
11
7
- id: elasticsearch
12
8
---
13
-
# Remote clusters security models
9
+
# Remote cluster security models
14
10
15
-
Remote clusters security models determine how authentication and authorization works between clusters. {{es}} has evolved from a TLS certificate–based model, relying on mutual TLS authentication over the transport interface and duplicated roles across clusters, to a more flexible API key–based model that uses a dedicated service endpoint and supports fine-grained authorization on both local and remote clusters.
11
+
Remote cluster security models determine how authentication and authorization works between clusters. {{es}} has evolved from a TLS certificate–based model, relying on mutual TLS authentication over the transport interface and duplicated roles across clusters, to a more flexible API key–based model that uses a dedicated service endpoint and supports fine-grained authorization on both local and remote clusters.
16
12
17
13
TLS certificate–based authentication is now deprecated, and users are encouraged to migrate to the API key–based model.
18
14
19
15
The following sections describe both models in detail and highlight their key differences.
20
16
21
-
::::{note}
17
+
::::{tip}
22
18
Security models work independently of [connection modes](./connection-modes.md). Both security models are compatible with either connection mode.
23
19
::::
24
20
25
21
## API key authentication [api-key]
26
22
27
-
API key authentication enables a local cluster to authenticate itself with a remote cluster via a [cross-cluster API key](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-create-cross-cluster-api-key). The API key needs to be created by an administrator of the remote cluster. The local cluster is configured to provide this API key on each request to the remote cluster. The remote cluster verifies the API key and grants access, based on the API key’s privileges.
23
+
API key authentication enables a local cluster to authenticate itself with a remote cluster using a [cross-cluster API key](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-create-cross-cluster-api-key). The API key needs to be created by an administrator of the remote cluster. The local cluster is configured to provide this API key on each request to the remote cluster. The remote cluster verifies the API key, and grants access based on the API key’s privileges.
28
24
29
25
### Authorization
30
26
31
27
With this security model, authorization is enforced jointly by the local and remote cluster, as follows:
32
28
33
-
* All cross-cluster requests from the local cluster are bound by the API key’s privileges, regardless of local users associated with the requests. For example, if the API key only allows read access to `my-index` on the remote cluster, even a superuser from the local cluster is limited by this constraint. This mechanism enables the remote cluster’s administrator to have full control over who can access what data with cross-cluster search and/or cross-cluster replication. The remote cluster’s administrator can be confident that no access is possible beyond what is explicitly assigned to the API key.
29
+
* All cross-cluster requests from the local cluster are bound by the API key’s privileges, regardless of local users associated with the requests. For example, if the API key only allows read access to `my-index` on the remote cluster, even a superuser from the local cluster is limited by this constraint. This mechanism enables the remote cluster’s administrator to have full control over who can access what data with cross-cluster search or cross-cluster replication. The remote cluster’s administrator can be confident that no access is possible beyond what is explicitly assigned to the API key.
34
30
35
-
* On the local cluster side, not every local user needs to access every piece of data allowed by the API key. An administrator of the local cluster can further configure additional permission constraints on local users so each user only gets access to the necessary remote data. Note it is only possible to further reduce the permissions allowed by the API key for individual local users. It is impossible to increase the permissions to go beyond what is allowed by the API key.
31
+
* On the local cluster side, not every local user needs to access every piece of data allowed by the API key. An administrator of the local cluster can further configure additional permission constraints on local users so each user only gets access to the necessary remote data. It is only possible to further reduce the permissions allowed by the API key for individual local users. It is impossible to increase the permissions to go beyond what is allowed by the API key.
36
32
37
33
::::{tip}
38
34
To configure fine-grained authorization for remote resources, use the `remote_indices` and `remote_clusters` fields in [role definitions](/deploy-manage/users-roles/cluster-or-deployment-auth/role-structure.md).
39
35
::::
40
36
41
37
### Connection details
42
38
43
-
In this model, cross-cluster operations use [a dedicated server port](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote_cluster.port) (remote cluster interface), for communication between clusters. The default port is `9443`. The remote cluster must enable this port for local clusters to connect.
39
+
In this model, cross-cluster operations use [a dedicated server port](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote_cluster.port), referred to as the remote cluster interface, for communication between clusters. The default port is `9443`. The remote cluster must enable this port for local clusters to connect.
44
40
45
41
From a TLS perspective, the local cluster must trust the remote cluster on the remote cluster interface. This means the local cluster must trust the certificate authority (CA) that signs the server certificate used by the remote cluster interface. When establishing a connection, all nodes from the local cluster that participate in cross-cluster communication verify certificates from nodes on the other side, based on the TLS trust configuration.
46
42
47
43
Mutual TLS is not required in this model.
48
44
49
45
### Setup
50
46
51
-
Refer to [Remote clusters setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.
47
+
Refer to [Remote cluster setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.
52
48
53
49
## TLS certificate authentication
54
50
```{applies_to}
@@ -71,7 +67,7 @@ The local cluster uses the [transport interface](elasticsearch://reference/elast
71
67
72
68
### Setup
73
69
74
-
Refer to [Remote clusters setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.
70
+
Refer to [Remote cluster setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.
0 commit comments