Traffic filtering is one of the security layers available in Elasticsearch Service. It 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.
Elasticsearch Service supports the following traffic sources:
IP addresses and Classless Inter-Domain Routing (CIDR) masks, e.g.
- AWS Virtual Private Clouds (VPCs) over AWS PrivateLink, supported only in AWS regions.
Filtering rules are grouped into rule sets, which in turn are associated with one or more deployments to take effect.
No need to worry about traffic between the instances in your deployment, that traffic is automatically allowed.
Traffic filter operates on the proxy. Requests rejected by the traffic filter are not forwarded to the deployment. The proxy responds to the client with
- Traffic filter rule
- Specifies traffic originating from an IP address, a CIDR mask, or an AWS VPC endpoint ID.
- Traffic filter rule set
- A named set of traffic filter rules. It defines allowed traffic sources. Rule sets can be used across multiple deployments. Note that the rules are not in effect until the rule set is associated with a deployment.
- Rule set association
- One or more rule sets can be associated with a deployment. In such a case, the traffic sources specified in the rule sets are allowed to connect to the deployment. No other traffic source is allowed.
How does it work?edit
By default, all your deployments are accessible over the public internet. They are not accessible over unknown PrivateLink connections.
Once you associate at least one traffic filter with a deployment, traffic that does not match any rules (for this deployment) is denied.
This only applies to external traffic. Internal traffic is managed by Elasticsearch Service. For example, Kibana can connect to Elasticsearch, as well as internal services which manage the deployment. Other deployments can’t connect to deployments protected by traffic filters. Given the limitation, clusters used for monitoring, storing leader indices for cross-cluster replication or search across as part of cross-cluster search cannot be configured with traffic filters.
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
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.
A default rule set is not automatically attached to existing deployments.
For more information about creating and editing rule sets and then associating them with your deployments, read more about IP addresses and CIDR masks and AWS Virtual Private Clouds (VPCs) over AWS PrivateLink.
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.
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 (e.g. use wrong IP address or VPC Endpoint ID) the deployment will be effectively locked down to any of your traffic. You can use the UI to adjust or remove the rule sets.
Jane creates a deployment. At this point the deployment is accessible over internet via its public endpoint, e.g.
https://fcd41689e9214319b1278325fd6af7cd.us-east-1.aws.found.io. The deployment is protected by username+password authentication, but there’s no additional traffic source filtering.
Jane wants to restrict access to the deployment so that only the traffic originating from Jane’s VPC is allowed.
- They create a Traffic Filter Private Link Endpoint rule set, thus registering their VPC with Elasticsearch Service.
- They associate this rule set with the deployment.
- At this point, their deployment is only accessible over PrivateLink from Jane’s VPC. This does not affect other security layers, so Jane’s users need to authenticate with username+password.
- The deployment is no longer accessible over the public internet endpoint.
Later on, Jane wants to allow access to the deployment from Jane’s Office.
They create an IP rule set with office IP range give as a CIDR mask, e.g.
- They attach the rule set to the deployment.
- The deployment is accessible from Jane’s VPC and from Jane’s Office.
Finally, Jane decides to allow anyone to connect to the deployment over the public internet.
They create the allow all rule set, with the CIDR mask
- They associate it with Jane’s deployment.
- Anyone with a valid username+password can now access the deployment.
They could remove the Jane’s Office rule set —
22.214.171.124/24. It is a subset of the allow all. They prefer to keep it attached anyways, in case they need to deny access from the public internet in the future.
This section offers suggestions on how to troubleshoot your traffic filters.
Review the rule sets associated with a deploymentedit
- Go to your deployment.
- Select the Security tab on the left-hand side menu bar.
- Traffic filter rule sets are listed under Traffic filters.
On this screen you can view and remove existing filters and attach new filters.
Identify default rule setsedit
To identify which rule sets are automatically applied to new deployments in your account:
- From the Account menu, select Traffic filters.
- You can see the list of traffic filter rule sets.
- Click on each of the rule sets — Include by default is checked when this rule set is automatically applied to all new deployments in its region.
How to view rejected requestsedit
Requests rejected by traffic filter have status code
403 Forbidden and response body