[Docs] Document IP filtering for RCS 2.0 (#98553)

This PR adds documentation for RCS 2.0 IP filtering.

Relates: #98472

docs/reference/settings/security-hash-settings.asciidoc

@@ -1,6 +1,6 @@
 [discrete]
 [[hashing-settings]]
-==== User cache and password hash algorithms
+=== User cache and password hash algorithms
 
 Certain realms store user credentials in memory. To limit exposure
 to credential theft and mitigate credential compromise, the cache only stores

docs/reference/settings/security-settings.asciidoc

@@ -2609,7 +2609,7 @@ setting, this would be `transport.profiles.$PROFILE.xpack.security.ssl.key`.
 
 [discrete]
 [[ip-filtering-settings]]
-==== IP filtering settings
+=== IP filtering settings
 You can configure the following settings for <<ip-filtering,IP filtering>>.
 
 `xpack.security.transport.filter.allow`::
@@ -2636,4 +2636,13 @@ List of IP addresses to allow for this profile.
 (<<dynamic-cluster-setting,Dynamic>>)
 List of IP addresses to deny for this profile.
 
+// TODO: fix the link to new page of API key based remote clusters
+`xpack.security.remote_cluster.filter.allow`::
+(<<dynamic-cluster-setting,Dynamic>>)
+beta:[] List of IP addresses to allow just for the remote cluster server.
+
+`xpack.security.remote_cluster.filter.deny`::
+(<<dynamic-cluster-setting,Dynamic>>)
+beta:[] List of IP addresses to deny just for the remote cluster server.
+
 include::security-hash-settings.asciidoc[]

x-pack/docs/en/security/using-ip-filtering.asciidoc

@@ -3,9 +3,9 @@
 == Restricting connections with IP filtering
 
 You can apply IP filtering to application clients, node clients, or transport
-clients, in addition to other nodes that are attempting to join the cluster.
+clients, remote cluster clients, in addition to other nodes that are attempting to join the cluster.
 
-If a node's IP address is on the blacklist, the {es} {security-features} allow
+If a node's IP address is on the denylist, the {es} {security-features} allow
 the connection to {es} but it is be dropped immediately and no requests are
 processed.
 
@@ -25,7 +25,8 @@ You configure IP filtering by specifying the `xpack.security.transport.filter.al
 `xpack.security.transport.filter.deny` settings in `elasticsearch.yml`. Allow rules
 take precedence over the deny rules.
 
-IMPORTANT: Unless explicitly specified, `xpack.security.http.filter.*` settings default to
+IMPORTANT: Unless explicitly specified, `xpack.security.http.filter.*` and
+`xpack.security.remote_cluster.filter.*` settings default to
 the corresponding `xpack.security.transport.filter.*` setting's value.
 
 [source,yaml]
@@ -110,9 +111,33 @@ xpack.security.http.filter.allow: 172.16.0.0/16
 xpack.security.http.filter.deny: _all
 --------------------------------------------------
 
+[discrete]
+=== Remote cluster (API key based model) filtering
+
+beta::[]
+
+If other clusters connect <<remote-clusters-api-key,using API key
+authentication>> for {ccs} or {ccr}, you may want to have different IP filtering
+for the remote cluster server interface.
+
+[source,yaml]
+--------------------------------------------------
+xpack.security.remote_cluster.filter.allow: 192.168.1.0/8
+xpack.security.remote_cluster.filter.deny: 192.168.0.0/16
+xpack.security.transport.filter.allow: localhost
+xpack.security.transport.filter.deny: '*.google.com'
+xpack.security.http.filter.allow: 172.16.0.0/16
+xpack.security.http.filter.deny: _all
+--------------------------------------------------
+
+NOTE: Whether IP filtering for remote cluster is enabled is controlled by
+`xpack.security.transport.filter.enabled` as well. This means filtering for
+the remote cluster and transport interfaces must be enabled or disabled together.
+But the exact allow and deny lists can be different between them.
+
 [discrete]
 [[dynamic-ip-filtering]]
-==== Dynamically updating IP filter settings
+=== Dynamically updating IP filter settings
 
 In case of running in an environment with highly dynamic IP addresses like cloud
 based hosting, it is very hard to know the IP addresses upfront when provisioning