By: Atif Siddiqui
Edited by: Jennifer Davis (@sigje)
Organizations aspire to apply the same security controls to ingress traffic in Cloud as they have on-premises, ideally taking advantage of Cloud value propositions to provide resiliency and scalability to traffic inspection appliances.
Within the AWS ecosystem, until last year, there wasn’t an elegant solution. Consequently, the most notable challenge it created, especially for regulated organizations, was designing the DMZ (demilitarized zone) pattern in AWS. It took two announcements to close this gap: VPC Ingress routing and Gateway Load Balancer (GWLB).
Two years ago, AWS announced VPC Ingress routing. This provided the capability where ingress traffic could be directed to an Elastic Network interface (ENI). Last year, Amazon followed it up with a complementary announcement of GWLB.
GWLB is AWS's fourth load balancer offering following Classic, Application and Network Load Balancer. Unlike the first three types, GWLB solves a niche problem and is, specifically, targeted towards partner appliances.
GWLB has a novel design with two distinct sides. The front end is connected to VPC endpoint service and corresponding VPC endpoints. This front end acts as a Layer 3 gateway. The backend is connected to third party appliances. This backend acts as a Layer 4 Load Balancer. An oversimplified diagram of the traffic flow is shown:
Ingress traffic → GWLB endpoints → GWLB endpoint service → GWLB → 3rd party appliance
So how do you provision a GWLB?
There are 4 key resources that need to be provisioned in order:
- Target Group
- GWLB using the above as the target group.
- VPC endpoint service using above as the load balancer type.
- VPC endpoints bound to the above endpoint service.
As part of this announcement, AWS implemented the GENEVE protocol and added this option to the UX for Target Group. If you are unfamiliar with this protocol it will be explained after going through GWLB provisioning requirements.
To configure this as infrastructure code (IaC), you could use a terraform code snippet as follows:
resource "aws_lb_target_group" "blog_gwlb_tgt_grp" {
name = "blog_gwlb_tgt_grp"
port = 6081
protocol = "GENEVE"
vpc_id = aws_vpc.fw.id
}
GWLB
As with Application Load Balancing, GWLB requires a target group to forward traffic; however, the target group must be created with the GENEVE protocol.
Health checks for TCP, HTTP and HTTPS are supported; however, it should be noted that health check packets are not GENEVE encapsulated.
An example of a terraform code snippet is as follows.
resource "aws_lb" "blog_gwlb" {
name = "blog_gwlb"
load_balancer_type = "gateway"
subnets = blog-gwlb-subnet.pvt.*.id
tags = {
Name = “blog-gwlb”,
Environment = "sandbox"
}
}
Endpoint Service
Prior to GWLB announcement, if an endpoint service was being created, the only option offered was Network Load Balancer (NLB). With GWLB’s availability, gateway is now the second option for load balancer type when creating an endpoint service. It should be noted that endpoint service whether it uses NLB or GWLB relies on the underlying PrivateLink technology.
An example of terraform code snippet is as follows.
resource "aws_vpc_endpoint_service" "blog-vpce-srvc" {
acceptance_required = false
gateway_load_balancer_arns = [aws_lb.blog-gwlb.arn]
tags = {
Name = “blog-gwlb”,
Environment = "sandbox"
}
}
VPC endpoint
The last key piece of the set is provisioning of VPC end points which will bind to end point service created in the prior step.
resource “aws_vpc_endpoint “blog_gwlbe” {
count = length(var.az)
service_name = aws_vpc_endpoint_service.blog-vpce-srvc.service_name
subnet_ids = [var.blog-gwlb-subnets[count.index]]
vpc_id = aws_vpc.fw.id
tags = {
Name = “blog-gwlb”,
Environment = "sandbox"
}
}
GENEVE
This is an encapsulation protocol created by the Internet Engineering Task Force (IETF). GENEVE stands for Generic Network Virtualization Encapsulation and leverages UDP for the transport layer. This encapsulation is what achieves the transparent routing of packets to third party appliances from vendors such as Big-IP, Palo Alto Networks, Aviatrix etc.
Special route table
The glue that blends VPC Ingress routing and GWLB feature is through a special use of route table.
Ingress traffic → GWLB endpoints → GWLB endpoint service → GWLB → 3rd party appliance e.g marketplace subscription.
This table does not have any explicit subnet association. It, however, has Internet Gateway (IGW) specified on the Edge associations.
Within routes, quad 0 points to Network interfaces (ENIs) of the Gateway Load Balancer endpoints (GWLBe).
It is this routing rule that enforces ingress traffic to be routed to GWLBe which in turns sends to GWLB (endpoint service) that is then routed to appliances.
Limitations
Target group using the GENEVE protocol does not support tags.
Cloud DMZ: Centralized Inspection Architecture
Conclusion
The pairing of VPC ingress routing and GWLB allows enterprises to have a much sought after security posture where now both ingress and egress traffic can undergo firewall inspection. This set of capability is, especially, notable when the Cloud DMZ architecture is being created.
Afterthought: AWS Network Firewall
It is always fascinating to me how AWS keeps vendors on their toes. There seems to be an aura of ineluctability where vendors strive to stay a step ahead of AWS’s offering. While customers can use marketplace subscriptions (e.g. firewall) with GWLB, there is a competing service by Amazon named AWS Network Firewall. This is essentially Firewall as a Service where VPC ingress routing primitive will be used to point to AWS Network Firewall which uses GWLB behind the scenes. It is easy to predict that AWS will push for new products that will compete in this space that will use GWLB under the hood.
Over time, choices will rise whether it is with AWS products or more vendors certifying their products with GWLB. This abundance will serve to only benefit customers with more choices in their pursuit of secure network architecture.
No comments:
Post a Comment