Network path between ALB and ECS Fargate task
As part of a conversation about whether or not we need end to end TLS, I am trying to understand the communication path between an ALB and the ECS Fargate tasks it targets. I'm assuming the ALB and service tasks are hosted on completely distinct instances? Are these instances logically part of my VPC or not? Is the traffic confined to my VPC or does it go via AWS network's? I am arguing there is nothing to gain with TLS between ALB and services, as long as we trust AWS network, but I cannot find official document to support my argument, other than a SO thread from a AWS employee. Can anyone shed some light? Thanks
The traffic from ALB and your Fargate task is inside your VPC. After you deployed an ALB, you can see in the network interfaces section (in the EC2 in console) that there are some network interfaces for the ALB. Same for the task. So the traffic uses the protection of transit on a VPC.
https://docs.aws.amazon.com/whitepapers/latest/logical-separation/vpc-and-accompanying-features.html
Anyway it's highly suggested to implement TLS from ALB and your task, for a zero trust network. ALB doesn't validate the certificate from your task, this means that you can create a self signed certificate, this give you the ability to still encrypt your traffic. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html
The load balancer establishes TLS connections with the targets using certificates that you install on the targets. The load balancer does not validate these certificates. Therefore, you can use self-signed certificates or certificates that have expired. Because the load balancer is in a virtual private cloud (VPC), traffic between the load balancer and the targets is authenticated at the packet level, so it is not at risk of man-in-the-middle attacks or spoofing even if the certificates on the targets are not valid.
Many customers have a "encrypt everywhere" policy which is why they would deploy TLS between the ALB and the workload (Fargate in this case). They might have that policy because of internal reasons or because of legislation or industry requirements. What does it add? Eavesdropping protection on the AWS network. As Miki says - zero trust networking.
Relevant questions
Failed to expose AWS ECS Fargate Service via ALB
asked 18 days agoDoes ALB send SNI information in TLS handshake to a back-end server
asked a month agoHow to establish connection between AWS Fargate task to an external SFTP server?
asked 10 days agoRDS DB migrations using ECS and Fargate
asked 2 years agoNetwork path between ALB and ECS Fargate task
Accepted Answerasked 4 months agoQ: What’s the difference between “an ALB configured with pass-through traffic without TLS offload” vs “a NLB configured to pass-through traffic without TLS offload” ?
Accepted Answerasked 2 months agoECS fails to remove a task from the load balancer target group?
asked a month agoALB Rewrite-path and alter
asked 4 months agoECS Fargate + Service Discovery + ALB
Accepted Answerasked 4 years agoAre there any best practices for sending logs from ECS on EC2, ECS on Fargate and other AWS services such as API GW, load balancers (and more AWS services) to Splunk?
asked 2 months ago
Thanks, that's great. Just begs the question as to what TLS adds here, as it is, afaik, solely a mean to protect against MITM.