[Docs] Document IP filtering for RCS 2.0

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,7 +3,7 @@
 == 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
 the connection to {es} but it is be dropped immediately and no requests are
@@ -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]
@@ -145,3 +146,61 @@ PUT /_cluster/settings
 NOTE: In order to avoid locking yourself out of the cluster, the default bound
       transport address will never be denied. This means you can always SSH into
       a system and use curl to apply changes.
+
+[discrete]
+=== Remote cluster (API key based model) filtering
+
+beta::[]
+
+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
+
+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
+a machine. Instead of changing the configuration file and restarting the node,
+you can use the _Cluster Update Settings API_. For example:
+
+[source,console]
+--------------------------------------------------
+PUT /_cluster/settings
+{
+  "persistent" : {
+    "xpack.security.transport.filter.allow" : "172.16.0.0/24"
+  }
+}
+--------------------------------------------------
+
+You can also dynamically disable filtering completely:
+
+[source,console]
+--------------------------------------------------
+PUT /_cluster/settings
+{
+  "persistent" : {
+    "xpack.security.transport.filter.enabled" : false
+  }
+}
+--------------------------------------------------
+// TEST[continued]
+
+NOTE: In order to avoid locking yourself out of the cluster, the default bound
+transport address will never be denied. This means you can always SSH into
+a system and use curl to apply changes.