blog-security-laptop-720x420.png

One of the security features available in Elasticsearch® Service (Elastic® Cloud) is traffic filtering. Traffic filtering enables network layer security by limiting access to the deployment from configured networks only. In addition to the security policies consisting of role based access control (RBAC) employing principle of least privilege, using traffic filtering in conjunction provides greater security.

Elasticsearch Service (Elastic Cloud) supports CIDR (Classless Inter-Domain Routing) or IP address based traffic filtering in the form of 199.226.244.0/24 or 82.102.25.74. It also integrates traffic from major cloud providers: Amazon Web Services (AWS) VPC over AWS PrivateLink, Azure Virtual Network (VNets), and Google Cloud (GCP) Private Service Connect, for their respective cloud provider regions.

In this post, we will look more closely on implementing a traffic filter for AWS-based deployment — either hosted directly on Elastic Cloud or a subscription from AWS Marketplace.

Traffic filter key features

Traffic filters consist of rule(s) that specify the source of traffic, such as IP/CIDR or AWS VPC endpoint, and rule sets, which are a set of traffic filter rules. Rule sets are then associated with the deployment and can restrict access to the deployment based on those rules.

By default, customers connect to deployment over the public internet. Customers can assign multiple rule sets to a single deployment, and traffic can match to any of the rule sets. If traffic doesn’t match any of the rule sets, then it is denied with the message {"ok":false,"message":"Forbidden"}. For example, customers can associate an IP address and an AWS PrivateLink traffic filter to the deployment. Customers then can access the deployment from that specific IP or from AWS VPC.

Traffic filter is available to all Elastic Cloud customers at all subscription levels at no additional cost.

High-level architecture

High-level architecture

AWS PrivateLink enables private connectivity from customer network (Service Consumer) to deployments in Elastic network (Service Provider). Service Consumer can be a resource in VPC or on-prem resource connecting to VPC and accessing Elastic Cloud deployment. AWS PrivateLink routes traffic from the customer’s VPC interface endpoint to Elastic endpoint service, and traffic stays within the AWS network without any exposure to public internet.

Note 1: Traffic in AWS PrivateLink is unidirectional: Service Consumer VPC -> Service Provider VPC.

Note 2: IP traffic filter allows ingress and egress (Beta, API only), meaning it is bidirectional.

Implementation

implementation

Note: The AWS PrivateLink endpoint should be in the same region as the Elastic Cloud deployment.

Create VPC endpoint

Create VPC endpoint

Create DNS record

Create DNS record
  • Create a CNAME Record and associate VPC endpoint (Copy from VPC service) in record.
comparison

Create rule set in Elastic Cloud

  • Log in to Elastic Cloud Console and click Manage for the selected deployment.
  • Go to Features and click Add traffic filter. Use VPC endpoint ID created earlier.
black and white comparison

Associate rule set to deployment

  • From the same Manage deployment page, go to Security and Apply traffic filters.
  • Select the newly created AWS PrivateLink filter.
security
Browser window instance launched in the configured VPC
Browser window instance launched in the configured VPC
Terminal
Terminal

Monitoring and dashboards

You can monitor your traffic filter configuration specially VPC and DNS logs for issues and traffic patterns. You can use out of the box Elastic VPC and Route53 integrations to ingest data and get pre-built dashboards.

VPC Flow Logs
Route 53

Conclusion

AWS PrivateLink traffic filter helps to secure Elastic Cloud deployments, mitigating network risk. It is relatively easy to implement AWS PrivateLink traffic filters and lock down your deployment to known network sources. Learn more about AWS PrivateLink in our documentation.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.