diff --git a/deploy-manage/security/_snippets/associate-filter.md b/deploy-manage/security/_snippets/associate-filter.md
new file mode 100644
index 0000000000..79acbdaede
--- /dev/null
+++ b/deploy-manage/security/_snippets/associate-filter.md
@@ -0,0 +1,3 @@
+1. Go to the deployment.
+2. On the **Security** page, under **Traffic filters** select **Apply filter**.
+3. Choose the filter you want to apply and select **Apply filter**.
\ No newline at end of file
diff --git a/deploy-manage/security/_snippets/create-filter.md b/deploy-manage/security/_snippets/create-filter.md
new file mode 100644
index 0000000000..129dd5ec17
--- /dev/null
+++ b/deploy-manage/security/_snippets/create-filter.md
@@ -0,0 +1,4 @@
+1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
+2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
+3. Under the **Features** tab, open the **Traffic filters** page.
+4. Select **Create filter**.
\ No newline at end of file
diff --git a/deploy-manage/security/_snippets/delete-ruleset.md b/deploy-manage/security/_snippets/delete-ruleset.md
new file mode 100644
index 0000000000..3cf7899c99
--- /dev/null
+++ b/deploy-manage/security/_snippets/delete-ruleset.md
@@ -0,0 +1,8 @@
+If you need to remove a rule set, you must first remove any associations with deployments.
+
+To delete a rule set with all its rules:
+
+1. [Remove any deployment associations](/deploy-manage/security/gcp-private-service-connect-traffic-filters.md#remove-filter-deployment).
+2. From the **Account** menu, select **Traffic filters**.
+3. Find the rule set you want to edit.
+4. Select the **Remove** icon. The icon is inactive if there are deployments assigned to the rule set.
\ No newline at end of file
diff --git a/deploy-manage/security/_snippets/eck-traffic-filtering.md b/deploy-manage/security/_snippets/eck-traffic-filtering.md
new file mode 100644
index 0000000000..cb7d47acd2
--- /dev/null
+++ b/deploy-manage/security/_snippets/eck-traffic-filtering.md
@@ -0,0 +1,3 @@
+:::{tip}
+Elastic recommends that you use Kubernetes network policies over IP traffic filters for {{eck}}. This is because, in containerized environments like Kubernetes, IP addresses are usually dynamic, making network policies a more robust option.
+:::
\ No newline at end of file
diff --git a/deploy-manage/security/_snippets/edit-ruleset.md b/deploy-manage/security/_snippets/edit-ruleset.md
new file mode 100644
index 0000000000..fe7fc21024
--- /dev/null
+++ b/deploy-manage/security/_snippets/edit-ruleset.md
@@ -0,0 +1,3 @@
+1. From the **Account** menu, select **Traffic filters**.
+2. Find the rule set you want to edit.
+3. Select the **Edit** icon.
\ No newline at end of file
diff --git a/deploy-manage/security/_snippets/remove-filter.md b/deploy-manage/security/_snippets/remove-filter.md
new file mode 100644
index 0000000000..5ee5f0b29b
--- /dev/null
+++ b/deploy-manage/security/_snippets/remove-filter.md
@@ -0,0 +1,4 @@
+If you want to remove any traffic restrictions from a deployment or delete a rule set, you’ll need to remove any rule set associations first. To remove an association through the UI:
+
+1. Go to the deployment.
+2. On the **Security** page, under **Traffic filters** select **Remove**.
\ No newline at end of file
diff --git a/deploy-manage/security/aws-privatelink-traffic-filters.md b/deploy-manage/security/aws-privatelink-traffic-filters.md
index c55524a4fa..b5dc8c4122 100644
--- a/deploy-manage/security/aws-privatelink-traffic-filters.md
+++ b/deploy-manage/security/aws-privatelink-traffic-filters.md
@@ -9,7 +9,9 @@ mapped_urls:
# AWS PrivateLink traffic filters
-Traffic filtering, to only AWS PrivateLink connections, is one of the security layers available in {{ecloud}}. It allows you to limit how your deployments can be accessed.
+Traffic filtering to only AWS PrivateLink connections is one of the security layers available in {{ech}}. It allows you to limit how your deployments can be accessed.
+
+Refer to [](/deploy-manage/security/traffic-filtering.md) to learn more about traffic filtering in {{ech}}, and how traffic filter rules work.
AWS PrivateLink establishes a secure connection between two AWS Virtual Private Clouds (VPCs). The VPCs can belong to separate accounts, i.e. a service provider and its service consumers. AWS routes the PrivateLink traffic within the AWS data center and never exposes it to the public internet. In such a configuration, {{ecloud}} is the third-party service provider and the customers are service consumers.
@@ -46,7 +48,7 @@ Transport client is not supported over PrivateLink connections.
PrivateLink Service is set up by Elastic in all supported AWS regions under the following service names:
-::::{dropdown} AWS Public Regions
+::::{dropdown} AWS public regions
| **Region** | **VPC Service Name** | **Private hosted zone domain name** | **AZ Names (AZ IDs)** |
| --- | --- | --- | --- |
| af-south-1 | `com.amazonaws.vpce.af-south-1.vpce-svc-0d3d7b74f60a6c32c` | `vpce.af-south-1.aws.elastic-cloud.com` | `af-south-1a` (`afs1-az1`), `af-south-1b` (`afs1-az2`), `af-south-1c` (`afs1-az3`) |
@@ -74,7 +76,7 @@ PrivateLink Service is set up by Elastic in all supported AWS regions under the
::::
-::::{dropdown} GovCloud Regions
+::::{dropdown} GovCloud regions
| **Region** | **VPC Service Name** | **Private hosted zone domain name** |
| --- | --- | --- |
| us-gov-east-1 (GovCloud) | `com.amazonaws.vpce.us-gov-east-1.vpce-svc-0bba5ffa04f0cb26d` | `vpce.us-gov-east-1.aws.elastic-cloud.com` |
@@ -93,11 +95,11 @@ The process of setting up the PrivateLink connection to your clusters is split b
| | 5. Interact with your deployments over PrivateLink. |
-## Ensure your VPC endpoint is in all availability zones supported by {{ecloud}} on the region for the VPC service [ec-aws-vpc-overlapping-azs]
+## Ensure your VPC is in all availability zones [ec-aws-vpc-overlapping-azs]
+
+Ensure your VPC endpoint is in all availability zones supported by {{ecloud}} on the region for the VPC service.
-::::{note}
Ensuring that your VPC is in all supported {{ecloud}} availability zones for a particular region avoids potential for a traffic imbalance. That imbalance may saturate some coordinating nodes and underutilize others in the deployment, eventually impacting performance. Enabling all supported {{ecloud}} zones ensures that traffic is balanced optimally.
-::::
You can find the zone name to zone ID mapping with AWS CLI:
@@ -150,18 +152,28 @@ The mapping will be different for your region. Our production VPC Service for `u
3. Test the connection.
- Find out the endpoint of your deployment. You can do that by selecting **Copy endpoint** in the Cloud UI. It looks something like `my-deployment-d53192.es.us-east-1.aws.found.io`. `my-deployment-d53192` is an alias, and `es` is the product you want to access within your deployment.
+ Find out the endpoint of your deployment. You can do that by selecting **Copy endpoint** in the Cloud UI. It looks something like:
+
+ ```
+ my-deployment-d53192.es.us-east-1.aws.found.io
+ ```
+
+ where `my-deployment-d53192` is an alias, and `es` is the product you want to access within your deployment.
To access your {{es}} cluster over PrivateLink:
* If you have a [custom endpoint alias](/deploy-manage/deploy/elastic-cloud/custom-endpoint-aliases.md) configured, you can use the custom endpoint URL to connect.
* Alternatively, use the following URL structure:
- `https://{{alias}}.{product}.{{private_hosted_zone_domain_name}}`
+ ```
+ https://{{alias}}.{product}.{{private_hosted_zone_domain_name}}
+ ```
For example:
- `https://my-deployment-d53192.es.vpce.us-east-1.aws.elastic-cloud.com`
+ ```text
+ https://my-deployment-d53192.es.vpce.us-east-1.aws.elastic-cloud.com
+ ```
::::{tip}
@@ -171,9 +183,12 @@ The mapping will be different for your region. Our production VPC Service for `u
You can test the AWS console part of the setup with a following curl (substitute the region and {{es}} ID with your cluster):
+ Request:
```sh
$ curl -v https://my-deployment-d53192.es.vpce.us-east-1.aws.elastic-cloud.com
- ..
+ ```
+ Response:
+ ```sh
* Server certificate:
* subject: CN=*.us-east-1.aws.elastic-cloud.com
* SSL certificate verify ok.
@@ -196,9 +211,9 @@ Follow these high-level steps to add private link rules to your deployments.
4. [Access the deployment over a private link](/deploy-manage/security/aws-privatelink-traffic-filters.md#ec-access-the-deployment-over-private-link).
-### Finding your VPC endpoint ID [ec-find-your-endpoint]
+### Find your VPC endpoint ID [ec-find-your-endpoint]
-Having trouble finding your VPC endpoint ID? You can find it in the AWS console.
+You can find your VPC endpoint ID in the AWS console:
:::{image} /deploy-manage/images/cloud-ec-private-link-endpoint-id.png
:alt: VPC Endpoint ID
@@ -210,21 +225,20 @@ Having trouble finding your VPC endpoint ID? You can find it in the AWS console.
Once you know your VPC endpoint ID you can create a private link traffic filter rule set.
-1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
-2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
-3. Under the **Features** tab, open the **Traffic filters** page.
-4. Select **Create filter**.
-5. Select **Private link endpoint**.
-6. Create your rule set, providing a meaningful name and description.
-7. Select the region for the rule set.
-8. Enter your VPC endpoint ID.
-9. Select if this rule set should be automatically attached to new deployments.
+
+:::{include} _snippets/create-filter.md
+:::
+1. Select **Private link endpoint**.
+2. Create your rule set, providing a meaningful name and description.
+3. Select the region for the rule set.
+4. Enter your VPC endpoint ID.
+5. Select if this rule set should be automatically attached to new deployments.
::::{note}
Each rule set is bound to a particular region and can be only assigned to deployments in the same region.
::::
-10. (Optional) You can [claim your VPC endpoint ID](/deploy-manage/security/claim-traffic-filter-link-id-ownership-through-api.md), so that no other organization is able to use it in a traffic filter ruleset.
+6. (Optional) You can [claim your VPC endpoint ID](/deploy-manage/security/claim-traffic-filter-link-id-ownership-through-api.md), so that no other organization is able to use it in a traffic filter ruleset.
The next step is to [associate the rule set](/deploy-manage/security/aws-privatelink-traffic-filters.md#ec-associate-traffic-filter-private-link-rule-set) with your deployments.
@@ -233,10 +247,8 @@ The next step is to [associate the rule set](/deploy-manage/security/aws-private
To associate a private link rule set with your deployment:
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Apply filter**.
-3. Choose the filter you want to apply and select **Apply filter**.
-
+:::{include} _snippets/associate-filter.md
+:::
### Access the deployment over a PrivateLink [ec-access-the-deployment-over-private-link]
@@ -247,11 +259,19 @@ Use the alias you’ve set up as CNAME DNS record to access your deployment.
::::
-If your deployment alias is `my-deployment-12ab9b` and it is located in `us-east-1` region you can access it under `https://my-deployment-12ab9b.es.vpce.us-east-1.aws.elastic-cloud.com`.
+If your deployment alias is `my-deployment-12ab9b` and it is located in `us-east-1` region you can access it at the following URL:
+
+```
+https://my-deployment-12ab9b.es.vpce.us-east-1.aws.elastic-cloud.com
+```
+Request:
```sh
$ curl -u 'username:password' -v https://my-deployment-d53192.es.vpce.us-east-1.aws.elastic-cloud.com
-..
+```
+
+Response:
+```
< HTTP/1.1 200 OK
..
```
@@ -271,28 +291,15 @@ The settings `xpack.fleet.agents.fleet_server.hosts` and `xpack.fleet.outputs` t
You can edit a rule set name or to change the VPC endpoint ID.
-1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
-2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
-3. Under the **Features** tab, open the **Traffic filters** page.
-4. Find the rule set you want to edit.
-5. Select the **Edit** icon.
-
+:::{include} _snippets/edit-ruleset.md
+:::
### Delete a PrivateLink rule set [ec-delete-traffic-filter-private-link-rule-set]
-If you need to remove a rule set, you must first remove any associations with deployments.
-
-To delete a rule set with all its rules:
-
-1. [Remove any deployment associations](/deploy-manage/security/aws-privatelink-traffic-filters.md#ec-remove-association-traffic-filter-private-link-rule-set).
-2. Under the **Features** tab, open the **Traffic filters** page.
-3. Find the rule set you want to edit.
-4. Select the **Remove** icon. The icon is inactive if there are deployments assigned to the rule set.
-
-
-### Remove a PrivateLink rule set association from your deployment [ec-remove-association-traffic-filter-private-link-rule-set]
+:::{include} _snippets/delete-ruleset.md
+:::
-To remove an association through the UI:
+### Remove a PrivateLink rule set association from your deployment [remove-filter-deployment]
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Remove**.
+:::{include} _snippets/remove-filter.md
+:::
diff --git a/deploy-manage/security/azure-private-link-traffic-filters.md b/deploy-manage/security/azure-private-link-traffic-filters.md
index f205b6f398..08a623d1e4 100644
--- a/deploy-manage/security/azure-private-link-traffic-filters.md
+++ b/deploy-manage/security/azure-private-link-traffic-filters.md
@@ -9,45 +9,9 @@ mapped_urls:
# Azure Private Link traffic filters
-$$$ec-azure-access-the-deployment-over-private-link$$$
+Traffic filtering to allow only Azure Private Link connections is one of the security layers available in {{ech}}. It allows you to limit how your deployments can be accessed.
-$$$ec-azure-allow-traffic-from-link-id$$$
-
-$$$ec-azure-associate-traffic-filter-private-link-rule-set$$$
-
-$$$ec-azure-create-traffic-filter-private-link-rule-set$$$
-
-$$$ec-azure-remove-association-traffic-filter-private-link-rule-set$$$
-
-$$$ec-find-your-resource-id$$$
-
-$$$ec-find-your-resource-name$$$
-
-$$$ec-private-link-azure-dns$$$
-
-$$$ec-private-link-azure-service-aliases$$$
-
-$$$ech-azure-access-the-deployment-over-private-link$$$
-
-$$$ech-azure-allow-traffic-from-link-id$$$
-
-$$$ech-azure-associate-traffic-filter-private-link-rule-set$$$
-
-$$$ech-azure-create-traffic-filter-private-link-rule-set$$$
-
-$$$ech-azure-remove-association-traffic-filter-private-link-rule-set$$$
-
-$$$ech-find-your-resource-id$$$
-
-$$$ech-find-your-resource-name$$$
-
-$$$ech-private-link-azure-dns$$$
-
-$$$ech-private-link-azure-service-aliases$$$
-
-Traffic filtering, to allow only Azure Private Link connections, is one of the security layers available in {{ecloud}}. It allows you to limit how your deployments can be accessed.
-
-Read more about [Traffic Filtering](/deploy-manage/security/traffic-filtering.md) for the general concepts behind traffic filtering in {{ecloud}}.
+Refer to [](/deploy-manage/security/traffic-filtering.md) to learn more about traffic filtering in {{ech}}, and how traffic filter rules work.
::::{note}
Azure Private Link filtering is supported only for Azure regions.
@@ -63,7 +27,7 @@ Private Link is a connection between an Azure Private Endpoint and a Azure Priva
Private Link Services are set up by Elastic in all supported Azure regions under the following aliases:
-::::{dropdown} Azure Public Regions
+::::{dropdown} Azure public regions
| **Region** | **Azure Private Link Service alias** | **Private hosted zone domain name** |
| --- | --- | --- |
| australiaeast | australiaeast-prod-012-privatelink-service.a0cf0c1a-33ab-4528-81e7-9cb23608f94e.australiaeast.azure.privatelinkservice | privatelink.australiaeast.azure.elastic-cloud.com |
@@ -111,7 +75,7 @@ The process of setting up the Private link connection to your clusters is split
2. Create a DNS record.
- 1. Create a *Private DNS Zone*. Get the private hosted zone domain name in *Azure Private Link Service Alias* for the name of the zone. For example, in *eastus2* use `privatelink.*eastus2*.azure.elastic-cloud.com` as the zone domain name. Using this zone domain name is required to ensure certificate names match.
+ 1. Create a *Private DNS Zone*. Get the private hosted zone domain name in *Azure Private Link Service Alias* for the name of the zone. For example, in `eastus2`, use `privatelink.eastus2.azure.elastic-cloud.com` as the zone domain name. Using this zone domain name is required to ensure certificate names match.
2. After creating the *Private DNS Zone*, associate the zone with your VNet by creating a [virtual network link](https://learn.microsoft.com/en-us/azure/dns/private-dns-getstarted-portal).
3. Then create a DNS A record pointing to the private endpoint. Use `*` as the record name, `A` as the type, and put the private endpoint IP address as the record value.
@@ -195,28 +159,39 @@ Let’s test the connection:
* If you have a [custom endpoint alias](/deploy-manage/deploy/elastic-cloud/custom-endpoint-aliases.md) configured, you can use the custom endpoint URL to connect.
- `https://{{alias}}.{product}.{{private_hosted_zone_domain_name}}`
+ ```
+ https://{{alias}}.{product}.{{private_hosted_zone_domain_name}}
+ ```
For example:
- `https://my-deployment-d53192.es.privatelink.eastus2.azure.elastic-cloud.com`
+ ```text
+ https://my-deployment-d53192.es.privatelink.eastus2.azure.elastic-cloud.com
+ ```
* Alternatively, use the following URL structure:
- `https://{{elasticsearch_cluster_ID}}.{private_hosted_zone_domain_name}:9243`
+ ```
+ https://{{elasticsearch_cluster_ID}}.{private_hosted_zone_domain_name}:9243
+ ```
For example:
- `https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243`
+ ```text
+ https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243
+ ```
-3. You can test the Azure portal part of the setup with the following command (substitute the region and {{es}} ID with your cluster).
+3. You can test the Azure portal part of the setup with the following command (substitute the region and {{es}} ID with your cluster):
+
+ ```sh
+ $ curl -v https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243
+ ```
The output should look like this:
```sh
- $ curl -v https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243
* Rebuilt URL to: https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243/
- * Trying 192.168.46.5... # <== note this IP address
+ * Trying 192.168.46.5... # note this IP address
..
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
@@ -232,8 +207,13 @@ Let’s test the connection:
4. In the event that the Private Link connection is not approved by {{ecloud}}, you’ll get an error message like the following. Double check that the filter you’ve created in the previous step uses the right resource name and GUID.
+ Request:
```sh
$ curl -v https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243
+ ```
+
+ Response:
+ ```sh
* Rebuilt URL to: https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243/
* Trying 192.168.46.5...
* connect to 192.168.46.5 port 9243 failed: No route to host
@@ -250,10 +230,8 @@ The next step is to [associate the rule set](/deploy-manage/security/aws-private
To associate a Private Link rule set with your deployment:
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Apply filter**.
-3. Choose the filter you want to apply and select **Apply filter**.
-
+:::{include} _snippets/associate-filter.md
+:::
### Access the deployment over a Private Link [ec-azure-access-the-deployment-over-private-link]
@@ -264,11 +242,19 @@ Use the alias you’ve set up as CNAME A record to access your deployment.
::::
-For example, if your {{es}} ID is `6b111580caaa4a9e84b18ec7c600155e` and it is located in `eastus2` region you can access it under `https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243`.
+For example, if your {{es}} ID is `6b111580caaa4a9e84b18ec7c600155e` and it is located in `eastus2` region you can access it at the following URL:
+
+```text
+https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243
+```
+Request:
```sh
$ curl -u 'username:password' -v https://6b111580caaa4a9e84b18ec7c600155e.privatelink.eastus2.azure.elastic-cloud.com:9243
-..
+```
+
+Response:
+```
< HTTP/1.1 200 OK
..
```
@@ -284,31 +270,21 @@ Similarly, the {{es}} host needs to be updated to propagate the Private Link URL
## Edit a Private Link connection [ec-azure-edit-traffic-filter-private-link-rule-set]
-You can edit a rule set name or to change the VPC endpoint ID.
-
-1. From the **Account** menu, select **Traffic filters**.
-2. Find the rule set you want to edit.
-3. Select the **Edit** icon.
+You can edit a rule set name or to change the endpoint ID.
+:::{include} _snippets/edit-ruleset.md
+:::
### Delete a Private Link rule set [ec-azure-delete-traffic-filter-private-link-rule-set]
-If you need to remove a rule set, you must first remove any associations with deployments.
-
-To delete a rule set with all its rules:
-
-1. [Remove any deployment associations](/deploy-manage/security/azure-private-link-traffic-filters.md#ec-azure-remove-association-traffic-filter-private-link-rule-set).
-2. From the **Account** menu, select **Traffic filters**.
-3. Find the rule set you want to edit.
-4. Select the **Remove** icon. The icon is inactive if there are deployments assigned to the rule set.
-
+:::{include} _snippets/delete-ruleset.md
+:::
-### Remove a Private Link rule set association from your deployment [ec-azure-remove-association-traffic-filter-private-link-rule-set]
-To remove an association through the UI:
+### Remove a Private Link rule set association from your deployment [remove-filter-deployment]
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Remove**.
+:::{include} _snippets/remove-filter.md
+:::
## Setting up an inter-region Private Link connection [ec-azure-inter-region-private-link]
diff --git a/deploy-manage/security/ec-traffic-filtering-through-the-api.md b/deploy-manage/security/ec-traffic-filtering-through-the-api.md
index b2cbdbc9d5..d17b76f4fb 100644
--- a/deploy-manage/security/ec-traffic-filtering-through-the-api.md
+++ b/deploy-manage/security/ec-traffic-filtering-through-the-api.md
@@ -1,38 +1,57 @@
---
applies_to:
deployment:
- ess: ga
+ ess:
+ ece:
mapped_urls:
- https://www.elastic.co/guide/en/cloud/current/ec-traffic-filtering-through-the-api.html
+ - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-traffic-filtering-through-the-api.html
---
-# Manage traffic filtering through the {{ecloud}} API [ec-traffic-filtering-through-the-api]
+# Manage traffic filters through the API [ec-traffic-filtering-through-the-api]
-This example demonstrates how to use the {{ecloud}} RESTful API to manage different types of traffic filters. We cover the following examples:
+This example demonstrates how to use the {{ecloud}} RESTful API or {{ece}} RESTful API or to manage different types of traffic filters. We cover the following examples:
* [Create a traffic filter rule set](ec-traffic-filtering-through-the-api.md#ec-create-a-traffic-filter-rule-set)
* [IP traffic filter ingress rule set](ec-traffic-filtering-through-the-api.md#ec-ip-traffic-filters-ingress-rule-set)
- * [IP traffic filter egress rule set](ec-traffic-filtering-through-the-api.md#ec-ip-traffic-filters-egress-rule-set)
- * [AWS Privatelink traffic filters](ec-traffic-filtering-through-the-api.md#ec-aws-privatelink-traffic-filters-rule-set)
- * [Azure Private Link traffic filters](ec-traffic-filtering-through-the-api.md#ec-azure-privatelink-traffic-filters-rule-set)
- * [GCP Private Service Connect traffic filters](ec-traffic-filtering-through-the-api.md#ec-gcp-private-service-connect-traffic-filters-rule-set)
+ * {{ech}} only:
+ * [IP traffic filter egress rule set](ec-traffic-filtering-through-the-api.md#ec-ip-traffic-filters-egress-rule-set)
+ * [AWS Privatelink traffic filters](ec-traffic-filtering-through-the-api.md#ec-aws-privatelink-traffic-filters-rule-set)
+ * [Azure Private Link traffic filters](ec-traffic-filtering-through-the-api.md#ec-azure-privatelink-traffic-filters-rule-set)
+ * [GCP Private Service Connect traffic filters](ec-traffic-filtering-through-the-api.md#ec-gcp-private-service-connect-traffic-filters-rule-set)
* [Update a traffic filter rule set](ec-traffic-filtering-through-the-api.md#ec-update-a-traffic-filter-rule-set)
* [Associate a rule set with a deployment](ec-traffic-filtering-through-the-api.md#ec-associate-rule-set-with-a-deployment)
* [Delete a rule set association with a deployment](ec-traffic-filtering-through-the-api.md#ec-delete-rule-set-association-with-a-deployment)
* [Delete a traffic filter rule set](ec-traffic-filtering-through-the-api.md#ec-delete-a-rule-set)
-Read through the main [Traffic Filtering](traffic-filtering.md) page to learn about the general concepts behind filtering access to your {{ech}} deployments.
+Refer to [](traffic-filtering.md) to learn about the general concepts behind filtering access to your {{ech}} and {{ece}} deployments.
+
+To learn more about these endpoints, refer to the reference for your deployment type:
+
+* [{{ecloud}} API](https://www.elastic.co/docs/api/doc/cloud/group/endpoint-deploymentstrafficfilter)
+* [{{ece}} API](https://www.elastic.co/docs/api/doc/cloud-enterprise/group/endpoint-deploymentstrafficfilter)
## Create a traffic filter rule set [ec-create-a-traffic-filter-rule-set]
### IP traffic filter ingress rule set [ec-ip-traffic-filters-ingress-rule-set]
+```{applies_to}
+deployment:
+ ess:
+ ece:
+```
Send a request like the following to create an IP traffic filter ingress rule set:
+::::{tab-set}
+:group: ech-ece
+
+:::{tab-item} {{ech}}
+:sync: ech
+
```sh
curl \
-H "Authorization: ApiKey $API_KEY" \
@@ -64,6 +83,37 @@ https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/rulesets \
`type`
: The type of the rule set. In the JSON object, we use `ip` for the ingress IP traffic filter. Currently, we support `ip`, `egress_firewall`, `vpce` (AWS Private Link), `azure_private_endpoint` and `gcp_private_service_connect_endpoint`. These are described in further detail below.
+:::
+:::{tab-item} {{ece}}
+:sync: ece
+
+```sh
+curl \
+-H "Authorization: ApiKey $API_KEY" \
+-H 'content-type: application/json' \
+https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets \
+-d '
+{
+ "name": "My IP filtering Ingress Rule Set",
+ "region": "ece-region",
+ "description": "",
+ "type": "ip",
+ "rules": [
+ {
+ "description": "Allow inbound traffic from IP address 192.168.131.0",
+ "source": "192.168.131.0"
+ },
+ {
+ "description": "Allow inbound traffic within CIDR block 192.168.132.6/22",
+ "source": "192.168.132.6/22"
+ }
+ ],
+ "include_by_default": false
+}
+'
+```
+:::
+::::
If the request is successful, a response containing a $RULESET_ID is returned. $RULESET_ID is required to update or delete the rule set itself, or it can be used to associate the rule set to a deployment.
@@ -75,6 +125,10 @@ If the request is successful, a response containing a $RULESET_ID is returned. $
### IP traffic filter egress rule set [ec-ip-traffic-filters-egress-rule-set]
+```{applies_to}
+deployment:
+ ess: beta
+```
Send a request like the following to create an IP traffic filter egress rule set:
@@ -82,7 +136,7 @@ Send a request like the following to create an IP traffic filter egress rule set
curl \
-H "Authorization: ApiKey $API_KEY" \
-H 'content-type: application/json' \
-https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets \
+https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/rulesets \
-d '
{
"name": "My IP filtering Egress Rule Set",
@@ -116,7 +170,11 @@ https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets \
: This can be `udp`, `tcp`, or `all`.
-## AWS Privatelink traffic filters [ec-aws-privatelink-traffic-filters-rule-set]
+### AWS Privatelink traffic filters [ec-aws-privatelink-traffic-filters-rule-set]
+```{applies_to}
+deployment:
+ ess:
+```
Send a request like the following to create an AWS PrivateLink traffic filter rule set:
@@ -145,6 +203,10 @@ To find the value for `source` for type `vpce`, check [Find your VPC endpoint ID
### Azure Private Link traffic filters [ec-azure-privatelink-traffic-filters-rule-set]
+```{applies_to}
+deployment:
+ ess:
+```
Send a request like the following to create an Azure Private Link traffic filter rule set:
@@ -173,7 +235,11 @@ https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/rulesets \
To find the value for `azure_endpoint_name` and `azure_endpoint_guid` for type `azure_private_endpoint`, check [Find your private endpoint resource name](azure-private-link-traffic-filters.md#ec-find-your-resource-name) and [Find your private endpoint resource ID](azure-private-link-traffic-filters.md#ec-find-your-resource-id). This setting is supported only in Azure regions.
-### GCP Private Service Connect traffic filters [ec-gcp-private-service-connect-traffic-filters-rule-set]
+### GCP Private Service Connect traffic filters [ec-gcp-private-service-connect-traffic-filters-rule-set]
+```{applies_to}
+deployment:
+ ess:
+```
Send a request like the following to create a GCP Private Service Connect traffic filter rule set:
@@ -202,9 +268,19 @@ To find the value for `source` for type `gcp_private_service_connect_endpoint`,
## Update a traffic filter rule set [ec-update-a-traffic-filter-rule-set]
+```{applies_to}
+deployment:
+ ess:
+ ece:
+```
Send a request like the following to update an IP traffic filter ingress rule set:
+::::{tab-set}
+:group: ech-ece
+
+:::{tab-item} {{ech}}
+:sync: ech
```sh
curl -XPUT \
-H "Authorization: ApiKey $API_KEY" \
@@ -230,12 +306,53 @@ https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/rulesets/$RULESE
}
'
```
+:::
+:::{tab-item} {{ece}}
+:sync: ece
+
+```sh
+curl -XPUT \
+-H "Authorization: ApiKey $API_KEY" \
+-H 'content-type: application/json' \
+https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID \
+-d '
+{
+ "name": "My IP filtering Ingress Rule Set",
+ "region": "ece-region",
+ "description": "",
+ "type": "ip",
+ "rules": [
+ {
+ "description": "Allow inbound traffic from IP address 192.168.131.0",
+ "source": "192.168.131.0"
+ },
+ {
+ "description": "Allow inbound traffic within CIDR block 192.168.132.6/22",
+ "source": "192.168.132.6/22"
+ }
+ ],
+ "include_by_default": true
+}
+'
+```
+:::
+::::
## Associate a rule set with a deployment [ec-associate-rule-set-with-a-deployment]
+```{applies_to}
+deployment:
+ ess:
+ ece:
+```
Send a request like the following to associate a rule set with a deployment:
+::::{tab-set}
+:group: ech-ece
+
+:::{tab-item} {{ech}}
+:sync: ech
```sh
curl -XPOST \
-H "Authorization: ApiKey $API_KEY" \
@@ -248,27 +365,89 @@ https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/rulesets/$RULESE
}
'
```
+:::
+:::{tab-item} {{ece}}
+:sync: ece
+
+```sh
+curl -XPOST \
+-H "Authorization: ApiKey $API_KEY" \
+-H 'content-type: application/json' \
+https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID/associations \
+-d '
+{
+ "entity_type" : "deployment",
+ "id" : "'"$DEPLOYMENT_ID"'"
+}
+'
+```
+:::
+::::
## Delete a rule set association with a deployment [ec-delete-rule-set-association-with-a-deployment]
+```{applies_to}
+deployment:
+ ess:
+ ece:
+```
Send a request like the following to delete a rule set association with a deployment:
+::::{tab-set}
+:group: ech-ece
+
+:::{tab-item} {{ech}}
+:sync: ech
+
```sh
curl -XDELETE \
-H "Authorization: ApiKey $API_KEY" \
-H 'content-type: application/json' \
https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID/associations/deployment/$DEPLOYMENT_ID \
```
+:::
+
+:::{tab-item} {{ece}}
+:sync: ece
+
+```sh
+curl -XDELETE \
+-H "Authorization: ApiKey $API_KEY" \
+-H 'content-type: application/json' \
+https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID/associations/deployment/$DEPLOYMENT_ID \
+```
+:::
+::::
## Delete a traffic filter rule set [ec-delete-a-rule-set]
+```{applies_to}
+deployment:
+ ess:
+ ece:
+```
Send a request like the following to delete a traffic filter rule set:
+::::{tab-set}
+:group: ech-ece
+
+:::{tab-item} {{ech}}
+:sync: ech
+
```sh
curl -XDELETE \
-H "Authorization: ApiKey $API_KEY" \
https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID \
```
-
+:::
+:::{tab-item} {{ece}}
+:sync: ece
+```sh
+curl -XDELETE \
+-H "Authorization: ApiKey $API_KEY" \
+https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID \
+```
+:::
+::::
\ No newline at end of file
diff --git a/deploy-manage/security/ece-traffic-filtering-through-the-api.md b/deploy-manage/security/ece-traffic-filtering-through-the-api.md
deleted file mode 100644
index f5ea31f365..0000000000
--- a/deploy-manage/security/ece-traffic-filtering-through-the-api.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-applies_to:
- deployment:
- ece: ga
-mapped_urls:
- - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-traffic-filtering-through-the-api.html
----
-
-# Manage traffic filtering through the ECE API [ece-traffic-filtering-through-the-api]
-
-This example demonstrates how to use the {{ece}} RESTful API to manage different types of traffic filters. We cover the following examples:
-
-* [Create a traffic filter rule set](ece-traffic-filtering-through-the-api.md#ece-create-a-traffic-filter-rule-set)
-
- * [IP traffic filter ingress rule set](ece-traffic-filtering-through-the-api.md#ece-ip-traffic-filters-ingress-rule-set)
-
-* [Update a traffic filter rule set](ece-traffic-filtering-through-the-api.md#ece-update-a-traffic-filter-rule-set)
-* [Associate a rule set with a deployment](ece-traffic-filtering-through-the-api.md#ece-associate-rule-set-with-a-deployment)
-* [Delete a rule set association with a deployment](ece-traffic-filtering-through-the-api.md#ece-delete-rule-set-association-with-a-deployment)
-* [Delete a traffic filter rule set](ece-traffic-filtering-through-the-api.md#ece-delete-a-rule-set)
-
-Read through the main [Traffic Filtering](traffic-filtering.md) page to learn about the general concepts behind filtering access to your {{ece}} deployments.
-
-
-## Create a traffic filter rule set [ece-create-a-traffic-filter-rule-set]
-
-
-### IP traffic filter ingress rule set [ece-ip-traffic-filters-ingress-rule-set]
-
-Send a request like the following to create an IP traffic filter ingress rule set:
-
-```sh
-curl \
--H "Authorization: ApiKey $API_KEY" \
--H 'content-type: application/json' \
-https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets \
--d '
-{
- "name": "My IP filtering Ingress Rule Set",
- "region": "ece-region",
- "description": "",
- "type": "ip",
- "rules": [
- {
- "description": "Allow inbound traffic from IP address 192.168.131.0",
- "source": "192.168.131.0"
- },
- {
- "description": "Allow inbound traffic within CIDR block 192.168.132.6/22",
- "source": "192.168.132.6/22"
- }
- ],
- "include_by_default": false
-}
-'
-```
-
-If the request is successful, a response containing a $RULESET_ID is returned. $RULESET_ID is required to update or delete the rule set itself, or it can be used to associate the rule set to a deployment.
-
-```sh
-{
- "id" : "5470a0010ebf437bb9294ea9fcba0ba0"
-}
-```
-
-
-
-
-
-
-## Update a traffic filter rule set [ece-update-a-traffic-filter-rule-set]
-
-Send a request like the following to update an IP traffic filter ingress rule set:
-
-```sh
-curl -XPUT \
--H "Authorization: ApiKey $API_KEY" \
--H 'content-type: application/json' \
-https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID \
--d '
-{
- "name": "My IP filtering Ingress Rule Set",
- "region": "ece-region",
- "description": "",
- "type": "ip",
- "rules": [
- {
- "description": "Allow inbound traffic from IP address 192.168.131.0",
- "source": "192.168.131.0"
- },
- {
- "description": "Allow inbound traffic within CIDR block 192.168.132.6/22",
- "source": "192.168.132.6/22"
- }
- ],
- "include_by_default": true
-}
-'
-```
-
-
-## Associate a rule set with a deployment [ece-associate-rule-set-with-a-deployment]
-
-Send a request like the following to associate a rule set with a deployment:
-
-```sh
-curl -XPOST \
--H "Authorization: ApiKey $API_KEY" \
--H 'content-type: application/json' \
-https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID/associations \
--d '
-{
- "entity_type" : "deployment",
- "id" : "'"$DEPLOYMENT_ID"'"
-}
-'
-```
-
-
-## Delete a rule set association with a deployment [ece-delete-rule-set-association-with-a-deployment]
-
-Send a request like the following to delete a rule set association with a deployment:
-
-```sh
-curl -XDELETE \
--H "Authorization: ApiKey $API_KEY" \
--H 'content-type: application/json' \
-https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID/associations/deployment/$DEPLOYMENT_ID \
-```
-
-
-## Delete a traffic filter rule set [ece-delete-a-rule-set]
-
-Send a request like the following to delete a traffic filter rule set:
-
-```sh
-curl -XDELETE \
--H "Authorization: ApiKey $API_KEY" \
-https://$COORDINATOR_HOST:12443/api/v1/deployments/traffic-filter/rulesets/$RULESET_ID \
-```
-
diff --git a/deploy-manage/security/gcp-private-service-connect-traffic-filters.md b/deploy-manage/security/gcp-private-service-connect-traffic-filters.md
index 25dcd94acc..edea0fb0aa 100644
--- a/deploy-manage/security/gcp-private-service-connect-traffic-filters.md
+++ b/deploy-manage/security/gcp-private-service-connect-traffic-filters.md
@@ -9,35 +9,9 @@ mapped_urls:
# GCP Private Service Connect traffic filters
+Traffic filtering to allow only Private Service Connect connections is one of the security layers available in {{ecloud}}. It allows you to limit how your deployments can be accessed.
-$$$ec-find-your-psc-connection-id$$$
-
-$$$ec-private-service-connect-uris$$$
-
-$$$ec-psc-access-the-deployment-over-psc$$$
-
-$$$ec-psc-associate-traffic-filter-psc-rule-set$$$
-
-$$$ec-psc-create-traffic-filter-psc-rule-set$$$
-
-$$$ec-psc-remove-association-psc-rule-set$$$
-
-$$$ech-find-your-psc-connection-id$$$
-
-$$$ech-private-service-connect-uris$$$
-
-$$$ech-psc-access-the-deployment-over-psc$$$
-
-$$$ech-psc-associate-traffic-filter-psc-rule-set$$$
-
-$$$ech-psc-create-traffic-filter-psc-rule-set$$$
-
-$$$ech-psc-remove-association-psc-rule-set$$$
-
-
-Traffic filtering, to allow only Private Service Connect connections, is one of the security layers available in {{ecloud}}. It allows you to limit how your deployments can be accessed.
-
-Read more about [Traffic Filtering](/deploy-manage/security/traffic-filtering.md) for the general concepts behind traffic filtering in {{ecloud}}.
+Refer to [](/deploy-manage/security/traffic-filtering.md) to learn more about traffic filtering in {{ech}}, and how traffic filter rules work.
::::{note}
Private Service Connect filtering is supported only for Google Cloud regions.
@@ -58,7 +32,7 @@ Private Service Connect connections are regional, your Private Service Connect E
Service Attachments are set up by Elastic in all supported GCP regions under the following URIs:
-::::{dropdown} GCP Public Regions
+::::{dropdown} GCP public regions
| **Region** | **Service Attachment URI** | **Private zone DNS name** |
| --- | --- | --- |
| `asia-east1` | `projects/cloud-production-168820/regions/asia-east1/serviceAttachments/proxy-psc-production-asia-east1-v1-attachment` | `psc.asia-east1.gcp.elastic-cloud.com` |
@@ -127,29 +101,42 @@ The process of setting up the Private link connection to your clusters is split
::::
- To access your {{es}} cluster over Private Link:,
+ To access your {{es}} cluster over Private Link:
* If you have a [custom endpoint alias](/deploy-manage/deploy/elastic-cloud/custom-endpoint-aliases.md) configured, you can use the custom endpoint URL to connect.
- `https://{{alias}}.{product}.{{private_hosted_zone_domain_name}}`
+ ```
+ https://{{alias}}.{product}.{{private_hosted_zone_domain_name}}
+ ```
For example:
- `https://my-deployment-d53192.es.psc.asia-southeast1.gcp.elastic-cloud.com`
+ ```text
+ https://my-deployment-d53192.es.psc.asia-southeast1.gcp.elastic-cloud.com
+ ```
* Alternatively, use the following URL structure:
- `https://{{elasticsearch_cluster_ID}}.{private_hosted_zone_domain_name}:9243`
+ ```
+ https://{{elasticsearch_cluster_ID}}.{private_hosted_zone_domain_name}:9243
+ ```
For example:
- `https://6b111580caaa4a9e84b18ec7c600155e.psc.asia-southeast1.gcp.elastic-cloud.com:9243`
+ ```text
+ https://6b111580caaa4a9e84b18ec7c600155e.psc.asia-southeast1.gcp.elastic-cloud.com:9243
+ ```
You can test the Google Cloud console part of the setup with the following command (substitute the region and {{es}} ID with your cluster):
+ Request:
```sh
$ curl -v https://6b111580caaa4a9e84b18ec7c600155e.psc.asia-southeast1.gcp.elastic-cloud.com:9243
+ ```
+
+ Response:
+ ```sh
..
* Trying 192.168.100.2...
..
@@ -184,19 +171,19 @@ Follow these high-level steps to add private link rules to your deployments.
When you have your Private Service Connect endpoint connection ID, you can create a traffic filter rule set.
-1. From the **Account** menu, select **Traffic filters**.
-2. Select **Create filter**.
-3. Select **Private Service Connect endpoint**.
-4. Create your rule set, providing a meaningful name and description.
-5. Select the region for the rule set.
-6. Enter your **PSC Connection ID**.
-7. Select if this rule set should be automatically attached to new deployments.
+:::{include} _snippets/create-filter.md
+:::
+1. Select **Private Service Connect endpoint**.
+2. Create your rule set, providing a meaningful name and description.
+3. Select the region for the rule set.
+4. Enter your **PSC Connection ID**.
+5. Select if this rule set should be automatically attached to new deployments.
::::{note}
Each rule set is bound to a particular region and can be only assigned to deployments in the same region.
::::
-8. (Optional) You can [claim your PSC Connection ID](/deploy-manage/security/claim-traffic-filter-link-id-ownership-through-api.md), so that no other organization is able to use it in a traffic filter ruleset.
+6. (Optional) You can [claim your PSC Connection ID](/deploy-manage/security/claim-traffic-filter-link-id-ownership-through-api.md), so that no other organization is able to use it in a traffic filter ruleset.
The next step is to [associate the rule set](/deploy-manage/security/aws-privatelink-traffic-filters.md#ec-associate-traffic-filter-private-link-rule-set) with your deployments.
@@ -205,10 +192,8 @@ The next step is to [associate the rule set](/deploy-manage/security/aws-private
To associate a private link rule set with your deployment:
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Apply filter**.
-3. Choose the filter you want to apply and select **Apply filter**.
-
+:::{include} _snippets/associate-filter.md
+:::
### Access the deployment over the Private Service Connect [ec-psc-access-the-deployment-over-psc]
@@ -219,11 +204,19 @@ Use the alias you’ve set up as CNAME A record to access your deployment.
::::
-For example, if your {{es}} ID is `6b111580caaa4a9e84b18ec7c600155e` and it is located in `asia-southeast1` region you can access it under `https://6b111580caaa4a9e84b18ec7c600155e.psc.asia-southeast1.gcp.elastic-cloud.com:9243`.
+For example, if your {{es}} ID is `6b111580caaa4a9e84b18ec7c600155e` and it is located in `asia-southeast1` region you can access it at the following URL:
+
+```
+https://6b111580caaa4a9e84b18ec7c600155e.psc.asia-southeast1.gcp.elastic-cloud.com:9243
+```
+Request:
```sh
$ curl -u 'username:password' -v https://6b111580caaa4a9e84b18ec7c600155e.psc.asia-southeast1.gcp.elastic-cloud.com:9243
-..
+```
+
+Response:
+```
< HTTP/1.1 200 OK
..
```
@@ -243,26 +236,17 @@ The settings `xpack.fleet.agents.fleet_server.hosts` and `xpack.fleet.outputs` t
You can edit a rule set name or to change the PSC connection ID.
-1. From the **Account** menu, select **Traffic filters**.
-2. Find the rule set you want to edit.
-3. Select the **Edit** icon.
+:::{include} _snippets/edit-ruleset.md
+:::
### Delete a Private Service Connect rule set [ec-psc-delete-psc-rule-set]
-If you need to remove a rule set, you must first remove any associations with deployments.
-
-To delete a rule set with all its rules:
-
-1. [Remove any deployment associations](/deploy-manage/security/gcp-private-service-connect-traffic-filters.md#ec-psc-remove-association-psc-rule-set).
-2. From the **Account** menu, select **Traffic filters**.
-3. Find the rule set you want to edit.
-4. Select the **Remove** icon. The icon is inactive if there are deployments assigned to the rule set.
-
+:::{include} _snippets/delete-ruleset.md
+:::
-### Remove a Private Service Connect rule set association from your deployment [ec-psc-remove-association-psc-rule-set]
-To remove an association through the UI:
+### Remove a Private Service Connect rule set association from your deployment [remove-filter-deployment]
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Remove**.
+:::{include} _snippets/remove-filter.md
+:::
\ No newline at end of file
diff --git a/deploy-manage/security/ip-filtering-basic.md b/deploy-manage/security/ip-filtering-basic.md
new file mode 100644
index 0000000000..47183fcbd2
--- /dev/null
+++ b/deploy-manage/security/ip-filtering-basic.md
@@ -0,0 +1,150 @@
+---
+mapped_urls:
+ - https://www.elastic.co/guide/en/elasticsearch/reference/current/ip-filtering.html
+applies_to:
+ deployment:
+ self:
+ eck:
+navigation_title: In ECK and Self Managed
+---
+
+# Manage IP traffic filters in ECK and self-managed clusters
+
+You can apply IP filtering to application clients, node clients, or transport 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 denylist, the {{es}} {{security-features}} allow the connection to {{es}} but it is be dropped immediately and no requests are processed.
+
+:::{note}
+{{es}} installations are not designed to be publicly accessible over the Internet. IP filtering and the other capabilities of the {{es}} {{security-features}} do not change this condition.
+:::
+
+:::{include} _snippets/eck-traffic-filtering.md
+:::
+
+## Enable IP filtering
+
+The {{es}} {{security-features}} contain an access control feature that allows or rejects hosts, domains, or subnets. If the [{{operator-feature}}](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md) is enabled, only operator users can update these settings.
+
+You configure IP filtering by specifying the `xpack.security.transport.filter.allow` and `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.*` and `xpack.security.remote_cluster.filter.*` settings default to the corresponding `xpack.security.transport.filter.*` setting’s value.
+:::
+
+
+```yaml
+xpack.security.transport.filter.allow: "192.168.0.1"
+xpack.security.transport.filter.deny: "192.168.0.0/24"
+```
+
+The `_all` keyword can be used to deny all connections that are not explicitly allowed.
+
+```yaml
+xpack.security.transport.filter.allow: [ "192.168.0.1", "192.168.0.2", "192.168.0.3", "192.168.0.4" ]
+xpack.security.transport.filter.deny: _all
+```
+
+IP filtering configuration also support IPv6 addresses.
+
+```yaml
+xpack.security.transport.filter.allow: "2001:0db8:1234::/48"
+xpack.security.transport.filter.deny: "1234:0db8:85a3:0000:0000:8a2e:0370:7334"
+```
+
+You can also filter by hostnames when DNS lookups are available.
+
+```yaml
+xpack.security.transport.filter.allow: localhost
+xpack.security.transport.filter.deny: '*.google.com'
+```
+
+
+## Disable IP filtering
+
+Disabling IP filtering can slightly improve performance under some conditions. To disable IP filtering entirely, set the value of the `xpack.security.transport.filter.enabled` setting in the `elasticsearch.yml` configuration file to `false`.
+
+```yaml
+xpack.security.transport.filter.enabled: false
+```
+
+You can also disable IP filtering for the transport protocol but enable it for HTTP only.
+
+```yaml
+xpack.security.transport.filter.enabled: false
+xpack.security.http.filter.enabled: true
+```
+
+
+## Specify TCP transport profiles
+
+[TCP transport profiles](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#transport-profiles) enable {{es}} to bind on multiple hosts. The {{es}} {{security-features}} enable you to apply different IP filtering on different profiles.
+
+```yaml
+xpack.security.transport.filter.allow: 172.16.0.0/24
+xpack.security.transport.filter.deny: _all
+transport.profiles.client.xpack.security.filter.allow: 192.168.0.0/24
+transport.profiles.client.xpack.security.filter.deny: _all
+```
+
+:::{note}
+When you do not specify a profile, `default` is used automatically.
+:::
+
+
+
+## HTTP filtering
+
+You may want to have different IP filtering for the transport and HTTP protocols.
+
+```yaml
+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
+```
+
+
+## Remote cluster (API key based model) filtering
+
+If other clusters connect [using API key authentication](/deploy-manage/remote-clusters/remote-clusters-api-key.md) for {{ccs}} or {{ccr}}, you may want to have different IP filtering for the remote cluster server interface.
+
+```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.
+:::
+
+## Dynamically update 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:
+
+```console
+PUT /_cluster/settings
+{
+ "persistent" : {
+ "xpack.security.transport.filter.allow" : "172.16.0.0/24"
+ }
+}
+```
+
+You can also dynamically disable filtering completely:
+
+```console
+PUT /_cluster/settings
+{
+ "persistent" : {
+ "xpack.security.transport.filter.enabled" : false
+ }
+}
+```
+
+:::{note}
+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.
+:::
\ No newline at end of file
diff --git a/deploy-manage/security/ip-filtering-cloud.md b/deploy-manage/security/ip-filtering-cloud.md
new file mode 100644
index 0000000000..db4b6fbda3
--- /dev/null
+++ b/deploy-manage/security/ip-filtering-cloud.md
@@ -0,0 +1,155 @@
+---
+mapped_pages:
+ - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-traffic-filtering-ip.html
+ - https://www.elastic.co/guide/en/cloud/current/ec-traffic-filtering-ip.html
+ - https://www.elastic.co/guide/en/cloud-heroku/current/ech-traffic-filtering-ip.html
+applies_to:
+ deployment:
+ ess: ga
+ ece: ga
+navigation_title: In ECH or ECE
+---
+
+# Manage IP traffic filters in ECH or ECE
+
+Traffic filtering, by IP address or CIDR block, is one of the security layers available in {{ece}} and {{ech}}. It allows you to limit how your deployments can be accessed.
+
+There are types of filters are available for filtering by IP address or CIDR block:
+
+* **Ingress or inbound IP filters**: These restrict access to your deployments from a set of IP addresses or CIDR blocks. These filters are available through the UI.
+* **Egress or outbound IP filters** (ECH only): These restrict the set of IP addresses or CIDR blocks accessible from your deployment. These might be used to restrict access to a certain region or service. This feature is in beta and is currently only available through the [Traffic Filtering API](/deploy-manage/security/ec-traffic-filtering-through-the-api.md).
+
+Follow the step described here to set up ingress or inbound IP filters through the {{ecloud}} Console or Cloud UI.
+
+To learn how traffic filter rules work together, refer to [traffic filter rules](/deploy-manage/security/traffic-filtering.md#traffic-filter-rules).
+
+To learn how to manage IP traffic filters using the Traffic Filtering API, refer to [](/deploy-manage/security/ec-traffic-filtering-through-the-api.md).
+
+:::{note}
+To learn how to create IP traffic filters for self-managed clusters or {{eck}} deployments, refer to [](ip-filtering-basic.md).
+:::
+
+## Prerequisites
+```{applies_to}
+deployment:
+ ece:
+```
+
+On {{ece}}, make sure your [load balancer](/deploy-manage/deploy/cloud-enterprise/ece-load-balancers.md) handles the `X-Forwarded-For` header appropriately for HTTP requests to prevent IP address spoofing. Make sure the proxy protocol v2 is enabled for HTTP and transport protocols (9243 and 9343).
+
+This step is not required in {{ech}}.
+
+## Apply an IP filter to a deployment
+
+To apply an IP filter to a deployment, you must first create a rule set at the organization or platform level, and then apply the rule set to your deployment.
+
+### Step 1: Create an IP filter rule set
+
+You can combine any rules into a set, so we recommend that you group rules according to what they allow, and make sure to label them accordingly. Since multiple sets can be applied to a deployment, you can be as granular in your sets as you feel is necessary.
+
+To create a rule set:
+
+1. Navigate to the traffic filters list:
+
+ ::::{tab-set}
+ :group: ech-ece
+
+ :::{tab-item} {{ech}}
+ :sync: ech
+ 1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
+ 2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
+ 3. Under the **Features** tab, open the **Traffic filters** page.
+ :::
+ :::{tab-item} {{ece}}
+ :sync: ece
+ 1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
+ 2. From the **Platform** menu, select **Security**.
+ :::
+ ::::
+
+2. Select **Create filter**.
+3. Select **IP filtering rule set**.
+4. Create your rule set, providing a meaningful name and description.
+5. Select the region for the rule set.
+6. Select if this rule set should be automatically attached to new deployments.
+
+ ::::{note}
+ Each rule set is bound to a particular region and can be only assigned to deployments in the same region.
+ ::::
+
+7. Add one or more rules using IPv4, or a range of addresses with CIDR.
+
+ ::::{note}
+ DNS names are not supported in rules.
+ ::::
+
+### Step 2: Associate an IP filter rule set with your deployment
+
+After you’ve created the rule set, you’ll need to associate IP filter rules with your deployment:
+
+1. Go to the deployment.
+2. On the **Security** page, under **Traffic filters**, select **Apply filter**.
+3. Choose the filter you want to apply and select **Apply filter**.
+
+At this point, the traffic filter is active. You can remove or edit it at any time.
+
+## Remove an IP filter rule set association from your deployment [remove-filter-deployment]
+
+If you want to remove any traffic restrictions from a deployment or delete a rule set, you’ll need to remove any rule set associations first. To remove an association through the UI:
+
+1. Go to the deployment.
+2. On the **Security** page, under **Traffic filters** select **Remove**.
+
+## Edit an IP filter rule set
+
+You can edit a rule set name or change the allowed traffic sources using IPv4, or a range of addresses with CIDR.
+
+1. Navigate to the traffic filters list:
+
+ ::::{tab-set}
+ :group: ech-ece
+
+ :::{tab-item} {{ech}}
+ :sync: ech
+ 1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
+ 2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
+ 3. Under the **Features** tab, open the **Traffic filters** page.
+ :::
+ :::{tab-item} {{ece}}
+ :sync: ece
+ 1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
+ 2. From the **Platform** menu, select **Security**.
+ :::
+ ::::
+
+2. Find the rule set you want to edit.
+5. Select the **Edit** icon.
+
+
+## Delete an IP filter rule set
+
+If you need to remove a rule set, you must first remove any associations with deployments.
+
+To delete a rule set with all its rules:
+
+1. [Remove any deployment associations](#remove-filter-deployment).
+1. Navigate to the traffic filters list:
+
+ ::::{tab-set}
+ :group: ech-ece
+
+ :::{tab-item} {{ech}}
+ :sync: ech
+ 1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
+ 2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
+ 3. Under the **Features** tab, open the **Traffic filters** page.
+ :::
+ :::{tab-item} {{ece}}
+ :sync: ece
+ 1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
+ 2. From the **Platform** menu, select **Security**.
+ :::
+ ::::
+
+3. Find the rule set you want to edit.
+4. Select the **Delete** icon. The icon is inactive if there are deployments assigned to the rule set.
\ No newline at end of file
diff --git a/deploy-manage/security/ip-traffic-filtering.md b/deploy-manage/security/ip-traffic-filtering.md
index bee688bbf0..ed447d4f87 100644
--- a/deploy-manage/security/ip-traffic-filtering.md
+++ b/deploy-manage/security/ip-traffic-filtering.md
@@ -6,354 +6,19 @@ applies_to:
eck: ga
self: ga
serverless: unavailable
-mapped_urls:
- - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-traffic-filtering-ip.html
- - https://www.elastic.co/guide/en/cloud/current/ec-traffic-filtering-ip.html
- - https://www.elastic.co/guide/en/cloud-heroku/current/ech-traffic-filtering-ip.html
- - https://www.elastic.co/guide/en/elasticsearch/reference/current/ip-filtering.html
---
# IP traffic filtering
-% Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc):
+This section covers traffic filtering by IP address or CIDR block.
+The way that you configure IP traffic filters depends on your deployment type:
+* **In {{ece}} and {{ech}}**, traffic filter rules are created at the organization or platform level, and then applied at the deployment level. [Learn how to create, apply and manage these rules](/deploy-manage/security/ip-filtering-cloud.md).
+
+ To learn how multiple rules are processed, and how IP traffic filters and [private link traffic filters](/deploy-manage/security/private-link-traffic-filters.md) work together in ECH, refer to [Traffic filter rules](/deploy-manage/security/traffic-filtering.md#traffic-filter-rules).
+* **In {{eck}} and self-managed clusters**, traffic filters are applied at the cluster level using `elasticsearch.yml`. [Learn how to configure traffic filtering at the cluster level](/deploy-manage/security/ip-filtering-basic.md).
-
-
-
-
-
-
-
-
-
-This page covers traffic filtering by IP address or CIDR block.
-
-Other [traffic filtering](/deploy-manage/security/traffic-filtering.md) methods are available depending on your deployment type.
-
-:::::{tab-set}
-:group: deployment-type
-
-::::{tab-item} {{ecloud}}
-:sync: cloud
-
-Traffic filtering, by IP address or CIDR block, is one of the security layers available in {{ecloud}}. It allows you to limit how your deployments can be accessed. We have two types of filters available for filtering by IP address or CIDR block: Ingress/Inbound and Egress/Outbound (Beta, API only).
-
-* **Ingress or inbound IP filters** - These restrict access to your deployments from a set of IP addresses or CIDR blocks. These filters are available through the {{ecloud}} Console.
-* **Egress or outbound IP filters** - These restrict the set of IP addresses or CIDR blocks accessible from your deployment. These might be used to restrict access to a certain region or service. This feature is in beta and is currently only available through the [Traffic Filtering API](/deploy-manage/security/ec-traffic-filtering-through-the-api.md).
-
-Read more about [Traffic Filtering](/deploy-manage/security/traffic-filtering.md) for the general concepts behind traffic filtering.
-
-Follow the step described here to set up ingress or inbound IP filters through the {{ecloud}} Console.
-
-
-**1. Create an IP filter rule set**
-
-You can combine any rules into a set, so we recommend that you group rules according to what they allow, and make sure to label them accordingly. Since multiple sets can be applied to a deployment, you can be as granular in your sets as you feel is necessary.
-
-To create a rule set:
-
-1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
-2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
-3. Under the **Features** tab, open the **Traffic filters** page.
-4. Select **Create filter**.
-5. Select **IP filtering rule set**.
-6. Create your rule set, providing a meaningful name and description.
-7. Select the region for the rule set.
-8. Select if this rule set should be automatically attached to new deployments.
-
- ::::{note}
- Each rule set is bound to a particular region and can be only assigned to deployments in the same region.
- ::::
-
-9. Add one or more rules using IPv4, or a range of addresses with CIDR.
-
- ::::{note}
- DNS names are not supported in rules.
- ::::
-
-
-The next step is to associate one or more rule-sets with your deployments.
-
-$$$ech-associate-traffic-filter-ip-rule-set$$$
-
-$$$ec-associate-traffic-filter-ip-rule-set$$$
-
-**2. Associate an IP filter rule set with your deployment**
-
-After you’ve created the rule set, you’ll need to associate IP filter rules with your deployment:
-
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Apply filter**.
-3. Choose the filter you want to apply and select **Apply filter**.
-
-At this point, the traffic filter is active. You can remove or edit it at any time.
-
-$$$ech-remove-association-traffic-filter-ip-rule-set$$$
-
-$$$ec-remove-association-traffic-filter-ip-rule-set$$$
-
-**Remove an IP filter rule set association from your deployment**
-
-If you want to remove any traffic restrictions from a deployment or delete a rule set, you’ll need to remove any rule set associations first. To remove an association through the UI:
-
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Remove**.
-
-
-**Edit an IP filter rule set**
-
-You can edit a rule set name or change the allowed traffic sources using IPv4, or a range of addresses with CIDR.
-
-1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
-2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
-3. Under the **Features** tab, open the **Traffic filters** page.
-4. Find the rule set you want to edit.
-5. Select the **Edit** icon.
-
-
-**Delete an IP filter rule set**
-
-If you need to remove a rule set, you must first remove any associations with deployments.
-
-To delete a rule set with all its rules:
-
-1. Remove any deployment associations.
-2. Under the **Features** tab, open the **Traffic filters** page.
-3. Find the rule set you want to edit.
-4. Select the **Delete** icon. The icon is inactive if there are deployments assigned to the rule set.
-
-
-
-::::
-
-::::{tab-item} {{ece}}
-:sync: cloud-enterprise
-
-Follow the step described here to set up ingress or inbound IP filters through the {{ece}} console.
-
-
-**1. Create an IP filter rule set**
-
-You can combine any rules into a set, so we recommend that you group rules according to what they allow, and make sure to label them accordingly. Since multiple sets can be applied to a deployment, you can be as granular in your sets as you feel is necessary.
-
-To create a rule set:
-
-1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
-2. From the **Platform** menu, select **Security**.
-3. Select **Create filter**.
-4. Select **IP filtering rule set**.
-5. Create your rule set, providing a meaningful name and description.
-6. Select if this rule set should be automatically attached to new deployments.
-
- ::::{note}
- Each rule set is bound to a particular region and can be only assigned to deployments in the same region.
- ::::
-
-7. Add one or more rules using IPv4, or a range of addresses with CIDR.
-
- ::::{note}
- DNS names are not supported in rules.
- ::::
-
-
-The next step is to associate one or more rule-sets with your deployments.
-
-$$$ece-associate-traffic-filter-ip-rule-set$$$
-
-**2. Associate an IP filter rule set with your deployment**
-
-After you’ve created the rule set, you’ll need to associate IP filter rules with your deployment:
-
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Apply filter**.
-3. Choose the filter you want to apply and select **Apply filter**.
-
-At this point, the traffic filter is active. You can remove or edit it at any time.
-
-$$$ece-remove-association-traffic-filter-ip-rule-set$$$
-
-**Remove an IP filter rule set association from your deployment**
-
-If you want to remove any traffic restrictions from a deployment or delete a rule set, you’ll need to remove any rule set associations first. To remove an association through the UI:
-
-1. Go to the deployment.
-2. On the **Security** page, under **Traffic filters** select **Remove**.
-
-
-**Edit an IP filter rule set**
-
-You can edit a rule set name or change the allowed traffic sources using IPv4, or a range of addresses with CIDR.
-
-1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
-2. From the **Platform** menu, select **Security**.
-3. Find the rule set you want to edit.
-4. Select the **Edit** icon.
-
-
-**Delete an IP filter rule set**
-
-If you need to remove a rule set, you must first remove any associations with deployments.
-
-To delete a rule set with all its rules:
-
-1. Remove any deployment associations.
-2. From the **Platform** menu, select **Security**.
-3. Find the rule set you want to edit.
-4. Select the **Delete** icon. The icon is inactive if there are deployments assigned to the rule set.
-
-
-::::
-
-
-::::{tab-item} Self-managed
-:sync: self-managed
-
-You can apply IP filtering to application clients, node clients, or transport 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 denylist, the {{es}} {{security-features}} allow the connection to {{es}} but it is be dropped immediately and no requests are processed.
-
-:::{note}
-{{es}} installations are not designed to be publicly accessible over the Internet. IP Filtering and the other capabilities of the {{es}} {{security-features}} do not change this condition.
-:::
-
-
-
-**Enabling IP filtering**
-
-The {{es}} {{security-features}} contain an access control feature that allows or rejects hosts, domains, or subnets. If the [{{operator-feature}}](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md) is enabled, only operator users can update these settings.
-
-You configure IP filtering by specifying the `xpack.security.transport.filter.allow` and `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.*` and `xpack.security.remote_cluster.filter.*` settings default to the corresponding `xpack.security.transport.filter.*` setting’s value.
-:::
-
-
-```yaml
-xpack.security.transport.filter.allow: "192.168.0.1"
-xpack.security.transport.filter.deny: "192.168.0.0/24"
-```
-
-The `_all` keyword can be used to deny all connections that are not explicitly allowed.
-
-```yaml
-xpack.security.transport.filter.allow: [ "192.168.0.1", "192.168.0.2", "192.168.0.3", "192.168.0.4" ]
-xpack.security.transport.filter.deny: _all
-```
-
-IP filtering configuration also support IPv6 addresses.
-
-```yaml
-xpack.security.transport.filter.allow: "2001:0db8:1234::/48"
-xpack.security.transport.filter.deny: "1234:0db8:85a3:0000:0000:8a2e:0370:7334"
-```
-
-You can also filter by hostnames when DNS lookups are available.
-
-```yaml
-xpack.security.transport.filter.allow: localhost
-xpack.security.transport.filter.deny: '*.google.com'
-```
-
-
-**Disabling IP Filtering**
-
-Disabling IP filtering can slightly improve performance under some conditions. To disable IP filtering entirely, set the value of the `xpack.security.transport.filter.enabled` setting in the `elasticsearch.yml` configuration file to `false`.
-
-```yaml
-xpack.security.transport.filter.enabled: false
-```
-
-You can also disable IP filtering for the transport protocol but enable it for HTTP only.
-
-```yaml
-xpack.security.transport.filter.enabled: false
-xpack.security.http.filter.enabled: true
-```
-
-
-**Specifying TCP transport profiles**
-
-[TCP transport profiles](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#transport-profiles) enable {{es}} to bind on multiple hosts. The {{es}} {{security-features}} enable you to apply different IP filtering on different profiles.
-
-```yaml
-xpack.security.transport.filter.allow: 172.16.0.0/24
-xpack.security.transport.filter.deny: _all
-transport.profiles.client.xpack.security.filter.allow: 192.168.0.0/24
-transport.profiles.client.xpack.security.filter.deny: _all
-```
-
-:::{note}
-When you do not specify a profile, `default` is used automatically.
-:::
-
-
-
-**HTTP filtering**
-
-You may want to have different IP filtering for the transport and HTTP protocols.
-
-```yaml
-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
-```
-
-
-**Remote cluster (API key based model) filtering**
-
-If other clusters connect [using API key authentication](/deploy-manage/remote-clusters/remote-clusters-api-key.md) for {{ccs}} or {{ccr}}, you may want to have different IP filtering for the remote cluster server interface.
-
-```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.
-:::
-
-
-
-**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:
-
-```console
-PUT /_cluster/settings
-{
- "persistent" : {
- "xpack.security.transport.filter.allow" : "172.16.0.0/24"
- }
-}
-```
-
-You can also dynamically disable filtering completely:
-
-```console
-PUT /_cluster/settings
-{
- "persistent" : {
- "xpack.security.transport.filter.enabled" : false
- }
-}
-```
-
-:::{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.
-:::
-
-
-::::
-
-
-:::::
+If you use {{ech}} or {{eck}}, then other [traffic filtering](/deploy-manage/security/traffic-filtering.md) methods are also available.
diff --git a/deploy-manage/security/k8s-network-policies.md b/deploy-manage/security/k8s-network-policies.md
index 9069d22a15..012c0ff8e4 100644
--- a/deploy-manage/security/k8s-network-policies.md
+++ b/deploy-manage/security/k8s-network-policies.md
@@ -15,6 +15,10 @@ This section describes how to use network policies to isolate the ECK operator a
Note that network policies alone are not sufficient for security. You should complement them with strict RBAC policies, resource quotas, node taints, and other available security mechanisms to ensure that tenants cannot access, modify, or disrupt resources belonging to each other.
+:::{tip}
+{{eck}} also supports [IP traffic filtering](/deploy-manage/security/ip-filtering-basic.md).
+:::
+
::::{note}
There are several efforts to support multi-tenancy on Kubernetes, including the [official working group for multi-tenancy](https://github.com/kubernetes-sigs/multi-tenancy) and community extensions such as [loft](https://loft.sh) and [kiosk](https://github.com/kiosk-sh/kiosk), that can make configuration and management easier. You might need to employ network policies such the ones described in this section to have fine-grained control over {{stack}} applications deployed by your tenants.
::::
@@ -58,8 +62,8 @@ The minimal set of permissions required are as follows:
| | |
| --- | --- |
-| Egress (outgoing) | * TCP port 443 of the Kubernetes API server.
* UDP port 53 for DNS lookup.
* TCP port 9200 of {{es}} nodes on managed namespace.
|
-| Ingress (incoming) | * TCP port 9443 for webhook requests from the Kubernetes API server.
|
+| Egress (outgoing) | • TCP port 443 of the Kubernetes API server.
• UDP port 53 for DNS lookup.
• TCP port 9200 of {{es}} nodes on managed namespace.
|
+| Ingress (incoming) | • TCP port 9443 for webhook requests from the Kubernetes API server.
|
```yaml
apiVersion: networking.k8s.io/v1
@@ -109,8 +113,8 @@ spec:
| | |
| --- | --- |
-| Egress (outgoing) | * TCP port 9300 to other {{es}} nodes in the namespace (transport port).
* UDP port 53 for DNS lookup.
|
-| Ingress (incoming) | * TCP port 9200 from the operator and other pods in the namespace.
* TCP port 9300 from other {{es}} nodes in the namespace (transport port).
|
+| Egress (outgoing) | • TCP port 9300 to other {{es}} nodes in the namespace (transport port).
• UDP port 53 for DNS lookup.
|
+| Ingress (incoming) | • TCP port 9200 from the operator and other pods in the namespace.
• TCP port 9300 from other {{es}} nodes in the namespace (transport port).
|
```yaml
apiVersion: networking.k8s.io/v1
@@ -171,8 +175,8 @@ spec:
| | |
| --- | --- |
-| Egress (outgoing) | * TCP port 9200 to {{es}} nodes in the namespace.
* UDP port 53 for DNS lookup.
|
-| Ingress (incoming) | * TCP port 5601 from other pods in the namespace.
|
+| Egress (outgoing) | • TCP port 9200 to {{es}} nodes in the namespace.
• UDP port 53 for DNS lookup.
|
+| Ingress (incoming) | • TCP port 5601 from other pods in the namespace.
|
```yaml
apiVersion: networking.k8s.io/v1
@@ -222,8 +226,8 @@ spec:
| | |
| --- | --- |
-| Egress (outgoing) | * TCP port 9200 to {{es}} nodes in the namespace.
* TCP port 5601 to {{kib}} instances in the namespace.
* UDP port 53 for DNS lookup.
|
-| Ingress (incoming) | * TCP port 8200 from other pods in the namespace.
|
+| Egress (outgoing) | • TCP port 9200 to {{es}} nodes in the namespace.
• TCP port 5601 to {{kib}} instances in the namespace.
• UDP port 53 for DNS lookup.
|
+| Ingress (incoming) | • TCP port 8200 from other pods in the namespace.
|
```yaml
apiVersion: networking.k8s.io/v1
@@ -282,7 +286,7 @@ Some {{beats}} may require additional access rules than what is listed here. For
| | |
| --- | --- |
-| Egress (outgoing) | * TCP port 9200 to {{es}} nodes in the namespace.
* TCP port 5601 to {{kib}} instances in the namespace.
* UDP port 53 for DNS lookup.
|
+| Egress (outgoing) | • TCP port 9200 to {{es}} nodes in the namespace.
• TCP port 5601 to {{kib}} instances in the namespace.
• UDP port 53 for DNS lookup.
|
```yaml
apiVersion: networking.k8s.io/v1
@@ -330,7 +334,7 @@ Some {{agent}} policies may require additional access rules other than those lis
| | |
| --- | --- |
-| Egress (outgoing) | * TCP port 9200 to {{es}} nodes in the namespace.
* TCP port 5601 to {{kib}} instances in the namespace.
* TCP port 8220 to {{fleet}} instances in the namespace.
* UDP port 53 for DNS lookup.
|
+| Egress (outgoing) | • TCP port 9200 to {{es}} nodes in the namespace.
• TCP port 5601 to {{kib}} instances in the namespace.
• TCP port 8220 to {{fleet}} instances in the namespace.
• UDP port 53 for DNS lookup.
|
```yaml
apiVersion: networking.k8s.io/v1
@@ -401,7 +405,7 @@ spec:
| | |
| --- | --- |
-| Egress (outgoing) | * TCP port 9200 to {{es}} nodes in the namespace.
* UDP port 53 for DNS lookup.
|
+| Egress (outgoing) | • TCP port 9200 to {{es}} nodes in the namespace.
• UDP port 53 for DNS lookup.
|
```yaml
apiVersion: networking.k8s.io/v1
diff --git a/deploy-manage/security/private-link-traffic-filters.md b/deploy-manage/security/private-link-traffic-filters.md
index 5c239c7ac2..3dd010e189 100644
--- a/deploy-manage/security/private-link-traffic-filters.md
+++ b/deploy-manage/security/private-link-traffic-filters.md
@@ -1,3 +1,23 @@
+---
+applies_to:
+ deployment:
+ ess: ga
+---
+
# Private link traffic filters
-landing page. TBD
\ No newline at end of file
+In {{ech}}, you can allow traffic between {{es}} and other resources hosted by the same cloud provider using private link services.
+
+Choose the relevant option for your cloud service provider:
+
+| Cloud service provider | Service |
+| --- | --- |
+| AWS | [AWS PrivateLink](/deploy-manage/security/aws-privatelink-traffic-filters.md) |
+| Azure | [Azure Private Link](/deploy-manage/security/azure-private-link-traffic-filters.md) |
+| GCP | [GCP Private Service Connect](/deploy-manage/security/gcp-private-service-connect-traffic-filters.md) |
+
+After you set up your private link, you can [claim ownership of your filter link ID](/deploy-manage/security/claim-traffic-filter-link-id-ownership-through-api.md) to prevent other organizations from using it in a traffic filter ruleset.
+
+:::{tip}
+{{ech}} also supports [IP traffic filters](/deploy-manage/security/ip-filtering-cloud.md).
+:::
diff --git a/deploy-manage/security/traffic-filtering.md b/deploy-manage/security/traffic-filtering.md
index 97fba30f97..8b60f40956 100644
--- a/deploy-manage/security/traffic-filtering.md
+++ b/deploy-manage/security/traffic-filtering.md
@@ -15,109 +15,108 @@ mapped_urls:
# Traffic filtering
-Traffic filtering allows you to limit how your deployments and clusters can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to *only* the sources that you trust.
+Traffic filtering allows you to limit how your deployments and clusters can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust.
-Depending on your deployment type you can use different mechanisms to restrict traffic, such as [IP filters](./ip-traffic-filtering.md), [private links](./private-link-traffic-filters.md) provided by cloud platforms, or [Kubernetes network policies](./k8s-network-policies.md).
+## Traffic filtering methods
+Depending on your deployment type you can use different mechanisms to restrict traffic.
::::{note}
This section covers traffic filtering at the deployment level. If you need the IP addresses used by {{ech}} to configure them in your network firewalls, refer to [](./elastic-cloud-static-ips.md).
+
+You can also allow traffic to or from a [remote cluster](/deploy-manage/remote-clusters.md) for use with cross-cluster replication or search.
::::
-:::::{tab-set}
-:group: deployment-type
+| Filter type | Description | Applicable deployment types |
+| --- | --- | --- |
+| [IP traffic filters](ip-traffic-filtering.md) | Filter traffic using IP addresses and Classless Inter-Domain Routing (CIDR) masks.
• [In ECH or ECE](/deploy-manage/security/ip-filtering-cloud.md)
• [In ECK or self-managed](/deploy-manage/security/ip-filtering-basic.md) | ECH, ECE, ECK, and self-managed clusters |
+| [Private link filters](/deploy-manage/security/private-link-traffic-filters.md) | Allow traffic between {{es}} and other resources hosted by the same cloud provider using private link services. Choose the relevant option for your region:
• AWS regions: [AWS PrivateLink](/deploy-manage/security/aws-privatelink-traffic-filters.md)
• Azure regions: [Azure Private Link](/deploy-manage/security/azure-private-link-traffic-filters.md)
• GCP regions: [GCP Private Service Connect](/deploy-manage/security/gcp-private-service-connect-traffic-filters.md) | {{ech}} only |
+| [Kubernetes network policies](/deploy-manage/security/k8s-network-policies.md) | Isolate pods by restricting incoming and outgoing network connections to a trusted set of sources and destinations. | {{eck}} only |
-::::{tab-item} {{ecloud}}
-:sync: cloud
+:::{include} _snippets/eck-traffic-filtering.md
+:::
-On {{ecloud}}, the following types of traffic filters are available for your {{ech}} deployments:
-| **Traffic filter type** | **Status** | **Description** |
-|------------|--------------|-------------|
-| IP traffic filters | [Configurable](ip-traffic-filtering.md) | IP addresses and Classless Inter-Domain Routing (CIDR) masks |
-| AWS VPCs over AWS PrivateLink | [Configurable](aws-privatelink-traffic-filters.md) | AWS PrivateLink filters. Can only be applied to {{ech}} deployments in AWS regions |
-| Azure Virtual Networks (VNets) | [Configurable](azure-private-link-traffic-filters.md) | Azure Private Link filters. Can only be applied to {{ech}} deployments in Azure regions |
-| GCP Private Service Connect | [Configurable](gcp-private-service-connect-traffic-filters.md) | GCP traffic filters. Can only be applied to {{ech}} deployments in GCP regions |
-| Ingress and Egress static IPs | [Configurable](elastic-cloud-static-ips.md) | Enable fixed IP addresses for traffic to and from {{ecloud}} |
-| Remote cluster connections | [Configurable](/deploy-manage/remote-clusters.md) | Secure cross-cluster operations |
+## Traffic filter rules in ECE and ECH [traffic-filter-rules]
+```{applies_to}
+ deployment:
+ ess:
+ ece:
+```
-**How does it work?**
+% could be refined further
-By default, all your {{ecloud}} deployments are accessible over the public internet. They are not accessible over unknown PrivateLink connections. This only applies to external traffic. Internal traffic is managed by {{ecloud}}. For example, {{kib}} can connect to {{es}}, as well as internal services which manage the deployment. Other deployments can’t connect to deployments protected by traffic filters.
+By default, in {{ece}} and {{ech}}, all your deployments are accessible over the public internet. In {{ece}}, this assumes that your orchestrator's proxies are accessible.
-In {{ecloud}} you can define traffic filters from the **Features** > **Traffic filters** page, and apply them to your {{ech}} deployments individually from their **Settings** page.
+Filtering *rules* are grouped into *rule sets*, which in turn are *associated* with one or more deployments to take effect. After you associate at least one traffic filter with a deployment, traffic that does not match any filtering rules for the deployment is denied.
-Once you associate at least one traffic filter with a deployment, traffic that does not match any rules (for this deployment) is denied.
+Traffic filters apply to external traffic only. Internal traffic is managed by ECE or ECH. For example, {{kib}} can connect to {{es}}, as well as internal services which manage the deployment. Other deployments can’t connect to deployments protected by traffic filters.
-:::{note}
Traffic filters operate on the proxy. Requests rejected by the traffic filters are not forwarded to the deployment. The proxy responds to the client with `403 Forbidden`.
+
Domain-based filtering rules are not allowed for Cloud traffic filtering, because the original IP is hidden behind the proxy. Only IP-based filtering rules are allowed.
-:::
-Filtering rules are grouped into rule sets, which in turn are associated with one or more deployments to take effect. You can have a maximum of 1024 rule sets per organization and 128 rules in each rule set. Rule sets work as follows:
+Rule sets work as follows:
-- You can assign multiple rule sets to a single deployment. The rule sets can be of different types. In case of multiple rule sets, traffic can match ANY of them. If none of the rule sets match the request is rejected with `403 Forbidden`.
-- Traffic filter rule sets are bound to a single region. The rule sets can be assigned only to deployments in the same region. If you want to associate a rule set with deployments in multiple regions you have to create the same rule set in all the regions you want to apply it to.
+- You can assign multiple rule sets to a single deployment. The rule sets can be of different types. In case of multiple rule sets, traffic can match ANY of them. If none of the rule sets match, the request is rejected with `403 Forbidden`.
+- Traffic filter rule sets are bound to a single region. The rule sets can be assigned only to deployments in the same region. If you want to associate a rule set with deployments in multiple regions, then you have to create the same rule set in all the regions you want to apply it to.
- You can mark a rule set as *default*. It is automatically attached to all new deployments that you create in its region. You can detach default rule sets from deployments after they are created. Note that a *default* rule set is not automatically attached to existing deployments.
-- Traffic filter rule sets when associated with a deployment will apply to all deployment endpoints, such as {{es}}, {{kib}}, APM Server, and others.
+- Traffic filter rule sets, when associated with a deployment, will apply to all deployment endpoints, such as {{es}}, {{kib}}, APM Server, and others.
- Any traffic filter rule set assigned to a deployment overrides the default behavior of *allow all access over the public internet endpoint; deny all access over Private Link*. The implication is that if you make a mistake putting in the traffic source (for example, specified the wrong IP address) the deployment will be effectively locked down to any of your traffic. You can use the UI to adjust or remove the rule sets.
+:::{admonition} Rule limits
+In {{ech}}, you can have a maximum of 1024 rule sets per organization and 128 rules in each rule set.
-::::
-
-::::{tab-item} ECE/ECK
-:sync: ece-eck
-
-**Available features**
+In {{ece}}, you can have a maximum of 512 rule sets per organization and 128 rules in each rule set.
+:::
-| **Traffic filter type** | **Status** | **Description** |
-|------------|--------------|-------------|
-| IP traffic filters | [Configurable](ip-traffic-filtering.md) | IP addresses and Classless Inter-Domain Routing (CIDR) masks |
-| AWS VPCs over AWS PrivateLink | N/A | X |
-| Azure Virtual Networks (VNets) | N/A | X |
-| GCP Private Service Connect | N/A | X |
-| Ingress and Egress static IPs | N/A | X |
-| Remote cluster connections | [Configurable](/deploy-manage/remote-clusters.md) | Secure cross-cluster operations |
+### Tips
-**Before you begin**
+This section offers suggestions on how to manage and analyze the impact of your traffic filters in ECH and ECE.
-On {{ece}}, make sure your [load balancer](/deploy-manage/deploy/cloud-enterprise/ece-load-balancers.md) handles the `X-Forwarded-For` header appropriately for HTTP requests to prevent IP address spoofing. Make sure the proxy protocol v2 is enabled for HTTP and transport protocols (9243 and 9343).
+#### Review the rule sets associated with a deployment
-**How does it work?**
+1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body) or [Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
+2. On the **Hosted deployments** page, select your deployment.
+3. Select the **Security** tab on the left-hand side menu bar.
-By default, all your deployments are accessible over the public internet, assuming that your orchestrator's proxies are accessible. This only applies to external traffic. Internal traffic is managed by the orchestrator. For example, {{kib}} can connect to {{es}}, as well as internal services which manage the deployment. Other deployments can’t connect to deployments protected by traffic filters.
+Traffic filter rule sets are listed under **Traffic filters**.
-You can define traffic filters from the **Platform** > **Security** page, and apply them to your {{ech}} deployments individually from their **Settings** page.
+On this page, you can view and remove existing filters and attach new filters.
-Once you associate at least one traffic filter with a deployment, traffic that does not match any rules (for this deployment) is denied.
+#### Identify default rule sets
+To identify which rule sets are automatically applied to new deployments in your account:
-:::{note}
-Traffic filters operate on the proxy. Requests rejected by the traffic filters are not forwarded to the deployment. The proxy responds to the client with `403 Forbidden`.
-Domain-based filtering rules are not allowed for Cloud traffic filtering, because the original IP is hidden behind the proxy. Only IP-based filtering rules are allowed.
-:::
+1. Navigate to the traffic filters list:
+
+ ::::{tab-set}
+ :group: ech-ece
-Filtering rules are grouped into rule sets, which in turn are associated with one or more deployments to take effect. You can have a maximum of 512 rule sets per organization and 128 rules in each rule set. Rule sets work as follows:
+ :::{tab-item} {{ech}}
+ :sync: ech
+ 1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
+ 2. Find your deployment on the home page in the **Hosted deployments** card and select **Manage** to access it directly. Or, select **Hosted deployments** to go to the **Deployments** page to view all of your deployments.
+ 3. Under the **Features** tab, open the **Traffic filters** page.
+ :::
+ :::{tab-item} {{ece}}
+ :sync: ece
+ 4. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md).
+ 5. From the **Platform** menu, select **Security**.
+ :::
+ ::::
-- You can assign multiple rule sets to a single deployment. The rule sets can be of different types. In case of multiple rule sets, traffic can match ANY of them. If none of the rule sets match the request is rejected with `403 Forbidden`.
-- Traffic filter rule sets are bound to a single region. The rule sets can be assigned only to deployments in the same region. If you want to associate a rule set with deployments in multiple regions you have to create the same rule set in all the regions you want to apply it to.
-- You can mark a rule set as *default*. It is automatically attached to all new deployments that you create in its region. You can detach default rule sets from deployments after they are created. Note that a *default* rule set is not automatically attached to existing deployments.
-- Traffic filter rule sets when associated with a deployment will apply to all deployment endpoints, such as {{es}}, {{kib}}, APM Server, and others.
-- Any traffic filter rule set assigned to a deployment overrides the default behavior of *allow all access over the public internet endpoint; deny all access over Private Link*. The implication is that if you make a mistake putting in the traffic source (for example, specified the wrong IP address) the deployment will be effectively locked down to any of your traffic. You can use the UI to adjust or remove the rule sets.
+2. Select each of the rule sets — **Include by default** is checked when this rule set is automatically applied to all new deployments in its region.
-::::
+#### View rejected requests
-:::{tab-item} Self-managed
-:sync: self-managed
+Requests rejected by traffic filter have status code `403 Forbidden` and one of the following in the response body:
-| **Traffic filter type** | **Status** | **Description** |
-|------------|--------------|-------------|
-| IP traffic filters | [Configurable](ip-traffic-filtering.md) | IP addresses and Classless Inter-Domain Routing (CIDR) masks |
-| AWS VPCs over AWS PrivateLink | N/A | X |
-| Azure Virtual Networks (VNets) | N/A | X |
-| GCP Private Service Connect | N/A | X |
-| Ingress and Egress static IPs | N/A | X |
-| Remote cluster connections | N/A | X |
+```json
+{"ok":false,"message":"Forbidden"}
+```
-:::
+```json
+{"ok":false,"message":"Forbidden due to traffic filtering. Please see the Elastic documentation on Traffic Filtering for more information."}
+```
-:::::
\ No newline at end of file
+Additionally, traffic filter rejections are logged in ECE proxy logs as `status_reason: BLOCKED_BY_IP_FILTER`. Proxy logs also provide client IP in `client_ip` field.
\ No newline at end of file
diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml
index c13f5fcefc..a7b62bf02c 100644
--- a/deploy-manage/toc.yml
+++ b/deploy-manage/toc.yml
@@ -472,8 +472,10 @@ toc:
children:
- file: security/ip-traffic-filtering.md
children:
- - file: security/ec-traffic-filtering-through-the-api.md
- - file: security/ece-traffic-filtering-through-the-api.md
+ - file: security/ip-filtering-cloud.md
+ children:
+ - file: security/ec-traffic-filtering-through-the-api.md
+ - file: security/ip-filtering-basic.md
- file: security/private-link-traffic-filters.md
children:
- file: security/aws-privatelink-traffic-filters.md
diff --git a/redirects.yml b/redirects.yml
new file mode 100644
index 0000000000..fd000d6b15
--- /dev/null
+++ b/redirects.yml
@@ -0,0 +1,2 @@
+redirects:
+ 'deploy-manage/security/ece-traffic-filtering-through-the-api.md': 'deploy-manage/security/ec-traffic-filtering-through-the-api.md'
\ No newline at end of file