3

I'm having a hard time figuring out how to set the correct SecurityGroup rules for my LoadBalancer. I have made a diagram to try and illustrate this problem, please take a look at the image below:

Our ECS setup

I have an internet facing LoadBalancer ("Service A LoadBalancer" in the diagram) that is requested from "inhouse" and from one of our ECS services ("Task B" in the diagram). For the inhouse requests, i can configure a SecurityGroup rule for "Service A LoadBalancer" that allows incoming request to the LoadBalancer on port 80 from the CIDR for our inhouse IP's. No problem there. But for the other ECS service, Task B, how would i go about adding a rule (for "Service A SecurityGroup" in the diagram) that only allows requests from Task B? (or only from tasks in the ECS cluster). Since it is an internet facing loadbalancer, requests are made from public ip of the machine EC2, not the private (as far as i can tell?).

I can obviously make a rule that allow requests on port 80 from 0.0.0.0/0, and that would work, but that's far from being restrictive enough. And since it is an internet facing LoadBalancer, adding a rule that allows requests from the "Cluster SecurityGroup" (in the diagram) will not cut it. I assume it is because the LB cannot infer from which SecurityGroup the request originated, as it is internet-facing - and that this would work if it was an internal LoadBalancer. But i cannot use an internal LoadBalancer, as it is also requested from outside AWS (Inhouse).

Any help would be appriciated.

Thanks Frederik

Frederik Nygaard Svendsen
  • 305
  • 1
  • 4
  • 14

1 Answers1

1

We solve this by running separate Internet facing and Internal Load Balancers. You can have multiple ELBs or ALBs (ELBv2) for the same cluster. Assuming your ECS clusters runs on an IP range such as 10.X.X.X you can open 10.X.0.0/16 for internal access on the internal ELB. Just make sure the ECS cluster SG also is open to the ELB. Task B can reach Task A over the internal ELB address assuming you use the DNS of the internal ELB address when making the request. If you hit the IP of a public DNS it will always be a public request.

However, you may want to think long term whether you really need a public ELB at all. Instead of IP restrictions, the next step is usually to run a VPN such as openVPN so you can connect into the VPC and access everything on the private network. We generally only ever run Internet Facing ELBs if we truly want something on the internet such as for external customers.

aaa572
  • 56
  • 3
  • 1
    Thanks for your answer. I also thought about having both types of LB (we use ALB), but i believe that it is not possible to set up several TargetGroups for the specific ECS Service? As it is ECS that assigns the container with the target group (we use dynamic port mapping, so ephemeral ports), i would essentially need it to either assign it to two target groups (one for the internal LB and one for the internet facing, but ECS only allows to set one TG for the Serivce), OR, assign the target group to two LB's. I believe neither of these options are possible, how did you do this? – Frederik Nygaard Svendsen Feb 09 '17 at 08:08
  • At the very least, we have other scenario's where a Service (task) is invoked both from another service (which again requires an internal LB) AND from a website, ClientSide. So in these situations the VPN solution will not cut it. – Frederik Nygaard Svendsen Feb 09 '17 at 08:12
  • 1
    We use ALB as well in this example. While it is true that an ECS Service can only be assigned to one target group, you can associate the same target group with multiple ALB Listener Rules. This is how we do this. We have two services that are on both internal & external ALBs. The same target group is just associated with listener rules on each internal & external ALB. I was able to verify that this is in fact how we do it this morning. You may also hit a limit that the ALB only supports 10 rules (right now). Because of this we also run multiple ALBs per cluster. – aaa572 Feb 10 '17 at 13:16
  • 1
    As far as the VPN, I only recommend that for the scenario above for your in house connections. A VPN allows you have your in-house users, connect to any of your private services as if they were on the private subnet. This is safer / easier than running things publicly, and having to verify everything is properly locked down. The VPN does not preclude you from having public services. In fact, we run ALL of our services on a private subnet. If we need to expose a service to public (outside our company), we just expose it via an ELB or ALB in a public subnet with rules to route to the service. – aaa572 Feb 10 '17 at 13:20
  • Thank you for your explanation @aaa572! I did not know it was possible to assign the TG to listener rules on different LB's! You really saved my day. Iwill look into this as soon as i get the chance – Frederik Nygaard Svendsen Feb 13 '17 at 09:18
  • 1
    Hello again @aaa572 I finally got around to setup your solution (assign one TargetGroup to two ApplicationLoadBalancers, an internal and an external). But AWS doesn't not allow that; after the TargetGroup is assigned to one ApplicationLoadBalancer, it is shown in the other loadbalancer as "Not available", when i add the listener for it. Could you please explain in further detail how this is set up for your account? That would help me a lot! Thanks in Advance - Frederik – Frederik Nygaard Svendsen Mar 09 '17 at 12:48
  • 1
    @FrederikNygaardHavlundSvend so I went and looked deeper again how we set up our specific micro-services that are both on private and public and it looks like I told you wrong. Last time I didn't notice the target group names for the ALB's which contain the same service are slightly different. It turns out we run duplicate copies of the micro-services, on separate clusters in order to assign them to different target groups and ELBs (one public, one internal). This only works as the services are stateless. Sorry for sending you down the wrong path initially, we have all of this automated. – aaa572 Mar 10 '17 at 13:35
  • Thats okay, thanks for checking up again for me! I think we might have to do the same in our case. What a shame though. Anyways, thanks for the help! – Frederik Nygaard Svendsen Mar 14 '17 at 10:29