How to Protect AWS ECS with SecureSphere WAF

Adoption of container technology is growing widely. More and more workloads are being transferred from traditional EC2 compute instances to container-based services. However, the need for securing the web traffic remains the same regardless of the elected platform.
In this post, we’ll deep dive into protecting web applications running on AWS ECS with SecureSphere WAF. While protecting ECS with SecureSphere is very similar to classic SecureSphere WAF deployment on AWS, we will cover the differences, and provide hints on the recommended way to protect the ECS cluster.

ECS Cluster Configuration

Amazon’s con­tainer web services run on ECS instances inside a VPC. It is important to configure the ECS instances on private subnets to ensure that the web traffic is only accessible through SecureSphere. It is also recommended to use an internal application load balancer (ALB) to access ECS services from a single DNS name – that way you can provision new services that will automatically be protected, without making any changes in SecureSphere.

Figure 1: Unprotected AWS ECS environment
In the above diagram (Figure 1), we have:

• An ECS cluster with ECS instances in two availability zones and in private subnets
• A public NAT instance/gateway configuration for the ECS instances to communicate with AWS API (ECS requirement)
• A green service, with containers spread across both ECS instances
  • The green service is registered to a target group in our internal ALB. Using the ALB rules, we will be able to register multiple ECS services to the same ALB with the same DNS endpoint:
    

Here our service is only accessible from inside the VPC so we need to deploy SecureSphere WAF for external access.

Deploying SecureSphere WAF

Deploying SecureSphere WAF is done using CloudFormation templates provided by Imperva. For more information on deployment check out this blog post.
Before deploying SecureSphere we need to set up the following resources:

• WAF private subnets (with outbound Internet routing to access AWS API)
• External load balancer (ELB)

After the deployment, our environment should look something like this (Figure 2):

Figure 2: ECS environment protected by SecureSphere WAF
 
Notes about the deployment:

• You can see that this deployment is suited for any web endpoint inside the VPC, not just ECS
• We used the “1 Subnet” GW template, a dual subnet template is also available
• The management server (MX) is in a private subnet, so you will not be able to access it from the Internet. You can access it from a jump box or using NAT routing
• The external ELB acts as our public endpoint. We need to configure DNS so that our green service hostname will be routed to the ELB. Usually our SSL termination will be on the ELB using an HTTPS listener

×

Apr 25 Upcoming Webinar

Build a Robust API Security Strategy in 2024 (APJ)

Register Now

SecureSphere Configuration

In our example environment, our networking configuration is simple – all web traffic passes through the ELB to our gateway scaling group, and from the gateways to the internal ALB. The ALB is responsible for routing to the appropriate ECS service based on host rules.
All we now have to do is configure a reverse proxy rule in the MX to route the traffic to the internal ALB:

Provisioning Additional ECS Services

We can now spin up new tasks and services in ECS that will automatically be protected without making any network changes in SecureSphere. If our new service, red uses the same SSL certificate as green, we can just:

• Attach the red service to a new target group in the internal ALB
• Route the red DNS to our external ELB

Because AWS load balancers don’t support SNI (both classic and application), if we want to use a different certificate for a new service (blue) we’ll need to create a new ELB to terminate the HTTPS and connect it to the gateway auto scaling group. After that, we can use the same GW stack and internal ALB – without making any changes to SecureSphere (Figure 3).

Figure 3: Multiple ECS services protected by a single SecureSphere WAF stack

Notes on SecureSphere Automation

In this blog post we demonstrated how to provision ECS services automatically without making any changes to the SecureSphere configuration. There will be different scenarios where this is not the case:

• Deploying a dedicated gateway stack (with/without MX) for an ECS service
• Updating reverse proxy rules to route to a newly added internal load balancer
• Uploading a new SSL certificate in the event SecureSphere terminates HTTPS

We’ll feature how to automate SecureSphere configuration for these deployment scenarios in future blog posts. To get started deploying SecureSphere in your ECS environment today, try our SecureSphere offering on the AWS Marketplace.