Network sec: rebrand and new cloud UX, IP filters in serverless #1785
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shainaraskas
changed the title
shainaraskas
commented
Jun 19, 2025
|
hey @alxchalkias, this is ready for review. Please loop in any devs who you'd like to review it as well. I left some open questions at the bottom of the PR description that you might be able to help me with. |
shainaraskas
commented
Jun 23, 2025
There was a problem hiding this comment.
todo: add "looking up secured resources" process
shainaraskas
commented
Jun 23, 2025
| @@ -3,5 +3,5 @@ | |||
| * **The transport layer**: Used mainly for inter-node communications, and in certain cases for cluster to cluster communication. | |||
| * In self-managed {{es}} clusters, you can also [Configure {{kib}} and {{es}} to use mutual TLS](/deploy-manage/security/kibana-es-mutual-tls.md). | |||
| * [Enable cipher suites for stronger encryption](/deploy-manage/security/enabling-cipher-suites-for-stronger-encryption.md): The TLS and SSL protocols use a cipher suite that determines the strength of encryption used to protect the data. You may want to enable the use of additional cipher suites, so you can use different cipher suites for your TLS communications or communications with authentication providers. | |||
| * [Restrict connections using traffic filtering](/deploy-manage/security/traffic-filtering.md): Traffic filtering allows you to limit how your deployments can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. Restrict access based on IP addresses or CIDR ranges, or, in {{ech}} deployments, secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. | |||
| * [Secure your network using IP filtering and private connectivity](/deploy-manage/security/traffic-filtering.md): Network security allows you to limit how your deployments can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. Restrict access based on IP addresses or CIDR ranges, or, in {{ech}} deployments, secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. | |||
There was a problem hiding this comment.
add vcp filtering here
Umbrella term: "VPC filtering/ers". For CSP-specific, we could use what they document, i.e.
Optional, however, we should push users to apply the policies for book-keeping/monitoring.
I think it's the region where the resource lives, but @igor-kupczynski or @cargious can chime in here. |
alxchalkias
reviewed
Jun 23, 2025
| @@ -1,7 +1,9 @@ | |||
| {{ecloud}} has built-in security. For example, HTTPS communications between {{ecloud}} and the internet, as well as inter-node communications, are secured automatically, and cluster data is encrypted at rest. | |||
|
|
|||
| In both {{ech}} amd {{serverless-full}}, you can also configure [IP filtering network security policies](/deploy-manage/security/ip-filtering-cloud.md) to prevent unauthorized access to your deployments and projects. | |||
There was a problem hiding this comment.
could this be just "IP filtering" to avoid the mouthful?
| In {{ech}}, you can augment these security features in the following ways: | ||
| * Configure [traffic filtering](/deploy-manage/security/traffic-filtering.md) to prevent unauthorized access to your deployments. | ||
| * [Configure private connectivity and apply VCPE filtering](/deploy-manage/security/traffic-filtering.md) to establish a secure connection for your {{ecloud}} deployments to communicate with other cloud services, and restrict traffic to deployments based on those private connections. |
There was a problem hiding this comment.
will the URL be refactored to remove the "traffic filtering" reference?
|
|
||
| For remote clusters configured using TLS certificate authentication, [traffic filtering](../security/traffic-filtering.md) can be enabled to restrict access to deployments that are used as a local or remote cluster without any impact to cross-cluster search or cross-cluster replication. | ||
| For remote clusters configured using TLS certificate authentication, [network security policies](../security/traffic-filtering.md) can be applies to restrict access to deployments that are used as a local or remote cluster without any impact to cross-cluster search or cross-cluster replication. |
There was a problem hiding this comment.
Suggested change
| For remote clusters configured using TLS certificate authentication, [network security policies](../security/traffic-filtering.md) can be applies to restrict access to deployments that are used as a local or remote cluster without any impact to cross-cluster search or cross-cluster replication. | |
| For remote clusters configured using TLS certificate authentication, [network security policies](../security/traffic-filtering.md) can be applied to restrict access to deployments that are used as a local or remote cluster without any impact on cross-cluster search or cross-cluster replication. |
| :::: | ||
|
|
||
| API key authentication for remote clusters cannot be used in combination with traffic filtering. | ||
| API key authentication for remote clusters cannot be used in combination with network security. |
There was a problem hiding this comment.
Suggested change
| API key authentication for remote clusters cannot be used in combination with network security. | |
| API key authentication for remote clusters cannot be used in combination with network security policies. |
| @@ -14,7 +14,7 @@ products: | |||
| This section explains how to configure a deployment to connect remotely to clusters belonging to a different {{ecloud}} organization. | |||
|
|
|||
| ::::{note} | |||
| If traffic filtering is enabled on the remote cluster, the remote cluster administrator must configure a traffic filter of type remote cluster, using either the organization ID or the Elasticsearch cluster ID as the filtering criteria. For detailed instructions, refer to [Remote clusters and traffic filtering](/deploy-manage/remote-clusters/ec-enable-ccs.md#ec-ccs-ccr-traffic-filtering). | |||
| If network security policies are applied to the remote cluster, the remote cluster administrator must configure a network security private connection policy of type remote cluster, using either the organization ID or the Elasticsearch cluster ID as the filtering criteria. For detailed instructions, refer to [Remote clusters and traffic filtering](/deploy-manage/remote-clusters/ec-enable-ccs.md#ec-ccs-ccr-traffic-filtering). | |||
There was a problem hiding this comment.
Suggested change
| If network security policies are applied to the remote cluster, the remote cluster administrator must configure a network security private connection policy of type remote cluster, using either the organization ID or the Elasticsearch cluster ID as the filtering criteria. For detailed instructions, refer to [Remote clusters and traffic filtering](/deploy-manage/remote-clusters/ec-enable-ccs.md#ec-ccs-ccr-traffic-filtering). | |
| If network security policies are applied to the remote cluster, the remote cluster administrator must configure a private connection of type remote cluster, using either the organization ID or the Elasticsearch cluster ID as the filtering criteria. For detailed instructions, refer to [Remote clusters and traffic filtering](/deploy-manage/remote-clusters/ec-enable-ccs.md#ec-ccs-ccr-traffic-filtering). |
| @@ -79,7 +79,7 @@ https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/link-ids/_claim | |||
| ``` | |||
|
|
|||
|
|
|||
| ## List claimed traffic filter link id [ec-list-claimed-traffic-filter-link-id] | |||
| ## List claimed IDs [ec-list-claimed-traffic-filter-link-id] | |||
There was a problem hiding this comment.
Suggested change
| ## List claimed IDs [ec-list-claimed-traffic-filter-link-id] | |
| ## List claimed private connection IDs [ec-list-claimed-traffic-filter-link-id] |
| @@ -89,7 +89,7 @@ https://api.elastic-cloud.com/api/v1/deployments/traffic-filter/link-ids \ | |||
| ``` | |||
|
|
|||
|
|
|||
| ## Unclaim a traffic filter link id [ec-unclaim-a-traffic-filter-link-id] | |||
| ## Claim a VCPE ID or Azure resource [ec-unclaim-a-traffic-filter-link-id] | |||
There was a problem hiding this comment.
Suggested change
| ## Claim a VCPE ID or Azure resource [ec-unclaim-a-traffic-filter-link-id] | |
| ## Unclaim a VCP ID or Azure resource [ec-unclaim-a-traffic-filter-link-id] |
|
|
||
| To create a rule set: | ||
| ### Step 1: Create an IP filter policy |
There was a problem hiding this comment.
Suggested change
| ### Step 1: Create an IP filter policy | |
| ### Step 1: Create an IP filter |
|
|
||
| 1. Navigate to the traffic filters list: | ||
| You can combine multiple IP address and CIDR block traffic sources into a single IP filter policy, so we recommend that you group sources according to what they allow, and make sure to label them accordingly. Because multiple sets can be applied to a deployment, you can be as granular in your policies as you feel is necessary. |
There was a problem hiding this comment.
Suggested change
| You can combine multiple IP address and CIDR block traffic sources into a single IP filter policy, so we recommend that you group sources according to what they allow, and make sure to label them accordingly. Because multiple sets can be applied to a deployment, you can be as granular in your policies as you feel is necessary. | |
| You can combine multiple IP addresses and CIDR block traffic sources into a single IP filter, so we recommend that you group sources according to what they allow, and make sure to label them accordingly. Because multiple IP filters can be applied to a deployment, you can be as granular in your policies as you deem necessary. |
| @@ -8,26 +8,26 @@ products: | |||
| - id: cloud-hosted | |||
| --- | |||
|
|
|||
| # Claim traffic filter link ID ownership through the API [ec-claim-traffic-filter-link-id-through-the-api] | |||
| # Claim VCPE ID or Azure resource ownership [ec-claim-traffic-filter-link-id-through-the-api] | |||
There was a problem hiding this comment.
Suggested change
| # Claim VCPE ID or Azure resource ownership [ec-claim-traffic-filter-link-id-through-the-api] | |
| # Claim VCP ID or Azure resource ownership [ec-claim-traffic-filter-link-id-through-the-api] |
alxchalkias
reviewed
Jun 23, 2025
|
|
||
| Network security policies are created at the organization level, and then are associated with one or more resources, such as a deployment or project, to take effect. After you associate at least one policy with a resource, traffic that does not match the policy or any other policy associated with the resource is denied. | ||
|
|
||
| Policies apply to external traffic only. Internal traffic is managed by the deployment or project. For example, in {{ech}}, {{kib}} can connect to {{es}}, as well as internal services which manage the deployment, Other deployments can’t connect to deployments protected by network security policies. |
There was a problem hiding this comment.
Suggested change
| Policies apply to external traffic only. Internal traffic is managed by the deployment or project. For example, in {{ech}}, {{kib}} can connect to {{es}}, as well as internal services which manage the deployment, Other deployments can’t connect to deployments protected by network security policies. | |
| Policies apply to external traffic only. Internal traffic is managed by the deployment or project. For example, in {{ech}}, {{kib}} can connect to {{es}}, as well as internal services which manage the deployment. Other deployments can’t connect to deployments protected by network security policies. |
|
|
||
| In {{ech}}, you can allow traffic between {{es}} and other resources hosted by the same cloud provider using private link services. | ||
| Private connectivity is a secure way for your {{ecloud}} deployments and projects to communicate with other cloud provider services over your cloud provider's private network. You can create a virtual private connection endpoint (VCPE) using your provider's private link service. You can also optionally filter traffic to your deployments and projects by creating ingress filters for your VCPE in {{ecloud}}. |
There was a problem hiding this comment.
Suggested change
| Private connectivity is a secure way for your {{ecloud}} deployments and projects to communicate with other cloud provider services over your cloud provider's private network. You can create a virtual private connection endpoint (VCPE) using your provider's private link service. You can also optionally filter traffic to your deployments and projects by creating ingress filters for your VCPE in {{ecloud}}. | |
| Private connectivity is a secure way for your {{ecloud}} deployments and projects to communicate with other cloud provider services over your cloud provider's private network. You can create a virtual private connection (VPC) using your provider's private link service. You can also optionally filter traffic to your deployments and projects by creating ingress filters for your VPC in {{ecloud}}. |
| @@ -16,8 +18,14 @@ Choose the relevant option for your cloud service provider: | |||
| | 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. | |||
| After you set up your private connection, you can [claim ownership of your VCPE ID](/deploy-manage/security/claim-traffic-filter-link-id-ownership-through-api.md) to prevent other organizations from using it. | |||
There was a problem hiding this comment.
Suggested change
| After you set up your private connection, you can [claim ownership of your VCPE ID](/deploy-manage/security/claim-traffic-filter-link-id-ownership-through-api.md) to prevent other organizations from using it. | |
| After you set up your private connection, you can [claim ownership of your VCP ID](/deploy-manage/security/claim-traffic-filter-link-id-ownership-through-api.md) to prevent other organizations from using it. |
| ::: | ||
|
|
||
| :::{note} | ||
| Private connection policies were formerly referred to as PrivateLink filters. |
There was a problem hiding this comment.
Suggested change
| Private connection policies were formerly referred to as PrivateLink filters. | |
| Private connection policies were formerly referred to as PrivateLink traffic filters. |
alxchalkias
reviewed
Jun 23, 2025
|
|
||
| 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. | ||
| * Record that you've established private connectivity between AWS and Elastic in the applicable region. | ||
| * Filter traffic to your deployment using VCPE filters. |
There was a problem hiding this comment.
Suggested change
| * Filter traffic to your deployment using VCPE filters. | |
| * Filter traffic to your deployment using VPC filters. |
|
|
||
| Follow these high-level steps to add private link rules to your deployments. | ||
| * Record that you've established private connectivity between AWS and Elastic in the applicable region. | ||
| * Filter traffic to your deployment using VCPE filters. |
There was a problem hiding this comment.
Suggested change
| * Filter traffic to your deployment using VCPE filters. | |
| * Filter traffic to your deployment using VPC filters. |
| ### Find your VPC endpoint ID [ec-find-your-endpoint] | ||
| ### Optional: Find your VPC endpoint ID [ec-find-your-endpoint] | ||
|
|
||
| The VPC endpoint ID is only required if you want to filter traffic to your deployment using VCPE filters. |
There was a problem hiding this comment.
Suggested change
| The VPC endpoint ID is only required if you want to filter traffic to your deployment using VCPE filters. | |
| The VPC endpoint ID is only required if you want to filter traffic to your deployment using VPC filters. |
|
|
||
| ### Associate a PrivateLink rule set with your deployment [ec-associate-traffic-filter-private-link-rule-set] | ||
| If the policy doesn't contain a VCPE filter, then the association can serve as a reminder that a VCP endpoint exists for the deployment's region. |
There was a problem hiding this comment.
Suggested change
| If the policy doesn't contain a VCPE filter, then the association can serve as a reminder that a VCP endpoint exists for the deployment's region. | |
| If the policy doesn't contain a VCPE filter, then the association can serve as a reminder that a VPC endpoint exists for the deployment's region. |
|
|
||
| For traffic to connect with the deployment over a PrivateLink, the client making the request needs to be located within the VPC where you’ve created the VPC endpoint. You can also setup network traffic to flow through the originating VPC from somewhere else, such as another VPC or VPN from your corporate network. This assumes that the VPC endpoint and the DNS record are also available within that context. Check your service provider documentation for setup instructions. | ||
| For traffic to connect with the deployment over a PrivateLink, the client making the request needs to be located within the VPC where you’ve created the VPC endpoint. You can also set up network traffic to flow through the originating VPC from somewhere else, such as another VPC or VPN from your corporate network. This assumes that the VPC endpoint and the DNS record are also available within that context. Check your service provider documentation for setup instructions. |
There was a problem hiding this comment.
Suggested change
| For traffic to connect with the deployment over a PrivateLink, the client making the request needs to be located within the VPC where you’ve created the VPC endpoint. You can also set up network traffic to flow through the originating VPC from somewhere else, such as another VPC or VPN from your corporate network. This assumes that the VPC endpoint and the DNS record are also available within that context. Check your service provider documentation for setup instructions. | |
| For traffic to connect with the deployment over a private connection, the client making the request needs to be located within the VPC where you’ve created the VPC endpoint. You can also set up network traffic to flow through the originating VPC from somewhere else, such as another VPC or VPN from your corporate network. This assumes that the VPC endpoint and the DNS record are also available within that context. Check your service provider documentation for setup instructions. |
|
|
||
| ## Considerations | ||
|
|
||
| Azure Private Link filtering is supported only for Azure regions. |
There was a problem hiding this comment.
Suggested change
| Azure Private Link filtering is supported only for Azure regions. | |
| Private connectivity with Azure Private Link is only supported in Azure regions. |
|
|
||
| AWS PrivateLink filtering is supported only for AWS regions. Elastic does not yet support cross-region AWS PrivateLink connections. Your PrivateLink endpoint needs to be in the same region as your target deployments. Additional details can be found in the [AWS VPCE Documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations). | ||
| Private connections over AWS PrivateLink are only supported only for AWS regions. Elastic does not yet support cross-region AWS PrivateLink connections. Your PrivateLink endpoint needs to be in the same region as your target deployments. Additional details can be found in the [AWS VPCE Documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations). |
There was a problem hiding this comment.
Suggested change
| Private connections over AWS PrivateLink are only supported only for AWS regions. Elastic does not yet support cross-region AWS PrivateLink connections. Your PrivateLink endpoint needs to be in the same region as your target deployments. Additional details can be found in the [AWS VPCE Documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations). | |
| Private connectivity with AWS PrivateLink is only supported in AWS regions. Elastic does not yet support cross-region AWS PrivateLink connections. Your PrivateLink endpoint needs to be in the same region as your target deployments. Additional details can be found in the [AWS VPCE Documentation](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations). |
|
|
||
| When you have your private endpoint name and ID, you can create a Private Link traffic filter rule set. | ||
| When you have your private endpoint ID, you can create a private connection policy. |
There was a problem hiding this comment.
Suggested change
| When you have your private endpoint ID, you can create a private connection policy. | |
| When you have your private endpoint name and ID, you can create a private connection policy. |
|
|
||
| * Private Service Connect filtering is supported only for Google Cloud regions. |
There was a problem hiding this comment.
Suggested change
| * Private Service Connect filtering is supported only for Google Cloud regions. | |
| * Private connectivity with Private Service Connect is only supported in Google Cloud regions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates the core pages related to traffic filtering to reflect the new ux (issue: https://github.com/elastic/platform-docs-team/issues/682)
This is PR 1 of 2 or 3. The first PR will capture the core changes needed to ship the feature. Subsequent PRs will update references to traffic filters other places in the docs, do any necessary API reference cleanup, etc.
Summary
This PR is pretty big, so you can use the links below to review it
Key changes
Network security and network security policies
Pulled policy/rule logic out of this page and into dedicated pages for Elastic Cloud and ECE
IP filters
Rebranded as "IP filter network security policies"
Updated all flows impacted by UX changes
snippet: wayfinding to network security page
Private connections
repositioned them as a connectivity strategy with VCPE filtering optional for everything but Azure
used deployment aliases to test/connect privatelink for consistency
snippets: wayfinding to network security page, associate filter, private url structure, find endpoint, fleet
used deployment aliases to test/connect privatelink for consistency
snippets: wayfinding to network security page, associate filter, private url structure, find endpoint, fleet
used deployment aliases to test/connect privatelink for consistency
snippets: wayfinding to network security page, associate filter, private url structure, find endpoint, fleet
Remote clusters
Access deployments of another Elastic Cloud organization
deploy-manage/remote-clusters/ec-remote-cluster-other-ess.md
Secondary changes
todo: serverless reference doc URL
Updated references to traffic filters to "network security" or "IP filtering and private connections" as needed, added IP filtering to the list of security features for serverless
deploy-manage/_snippets/ecloud-security.md
snippets: security in elastic cloud, features for cluster communication and network security, feature comparison
snippets: features for cluster communication and network security, feature comparison
Open questions
Is the umbrella term for private connection filters "VCPE filtering" (e.g. "add a private connection, then filter traffic to your deployment using VCPE filters")? Will this term be used for GCP?ANSWER: It's "VPC filtering"
For Azure, is associating a private connection policy with a deployment required, or optional?ANSWER: technically optional but strongly recommended
For Azure inter-region private links, what region should the associated policy be created in?
SR TODO