[ECS] Do you need to configure security groups to communicate over localhost?

0

Say I have two services (service-a and service-b) where service-a is a REPLICA service and service-b is a DAEMON service. They're on the same container instance. In order for service-a to communicate with service-b over localhost, will I need to configure a security group rule to do so?

I know you don't need to do it for two containers on the same task definition, but I'm not sure for two services in the same container instance.

asked 2 years ago2492 views
3 Answers
1
Accepted Answer

When running in bridge / host/ network modes, it works pretty much the same way as you'd expect to do if you'd run docker-compose up locally. Meaning, it is your own business to deal with network permissions (now, there can be the caveat of using proxy sidecar i.e. envoy but I honestly did not test that). I use awsvpc (and recommend to only use) network mode (although that does not apply if you use ECS Anywhere). In which case, your two containers although running on the same machine, can't talk to each other without using the associate ENI. This is very secure, just needs a little more management. Now, in both cases (awsvpc and others), I would recommend you'd not rely on the localhost "catch-all" you might get given you will have a service in DAEMON mode. I'd recommend instead to use service discovery with CloudMap: your service A and B will get registered in there. Whether you use one mode or another, the container will be registered in DNS with a SRV record (which also nicely deals with potential exposed port change). Your service A will always be able to talk to service B and makes for much more scalable option. It will future proof everything for you to expand and add more services as this is an easy, repeatable, and consistent process.

Hope this helps.

profile picture
answered 2 years ago
profile picture
EXPERT
reviewed 9 months ago
  • If you were interested, checkout ECS Compose-X which can take care of dealing with taking your services you might have working all good locally using docker-compose by running just a few commands. Disclaimer, I am the maintainer of that :) If your use-case allows (and the services support features you need) you might checkout AppRunner/Copilot.

  • Thanks! We're looking at implementing our services in awsvpc mode.

    Say we have replica-service-a and daemon-service-b. We scale up replica-service-a to take up 2 container instances. Using service discovery instead of localhost, how can we ensure that replica-service-a communicates with daemon-service-b in the same container instance?

    Will it require querying CloudMap and selecting the right IP address? Or is there a more automated way?

  • Right. So, if you want to ensure that the service A talks to service B of the same container instance, then questions ->

    1. is there a reason for it to have to talk to the container on the same instance ?
    2. that would not work at all if you wanted to move into Fargate (and although some features you can't use in Fargate so maybe that rules it out which is fair) and to answer your question, yes, you would want to use CloudMap to then query it and do client side service discovery -> allows you to search all instances of B which will have the attributes (EC2_INSTANCE_ID).
  • PS: was hitting the 600 chars comment limit: see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html for the attributes ECS sets for you in CloudMap. You see the EC2_INSTANCE_ID attribute there. Find your own (from service A) and use that in the request to find service B.

0

Update: I don't mean in my answer that localhost will be useable. localhost in container does not resolve to the host IP so it will never work regardless awsvpc or bridge mode. My answer below answers the question about security gorup.

It depends on the network mode you are using for your tasks. the default is bridge mode which does not have security groups support.

Having said that AWS recommends to use awsvpc for your tasks, in the awsvpc tasks get an ENI. This allows the task to have a security group which in-turn allows you to control the inbound and outbound traffic of the task.

answered 2 years ago
profile picture
EXPERT
reviewed 9 months ago
  • Got it. So in awsvpc, you'd still have to configure your security groups to communicate over localhost?

  • If you have 2 containers in the same task definition (and therefore service, no). However, no, you can't use localhost to go from container A to B (or B to A) when using awsvpc mode. See my reply.

  • NickHolden, the localhost inside container will not resolve to the host IP or other service ip. You should not be using localhost anyway even if it resolves to your desired IP, as explained by John.

0

On ECS, all Tasks (with the exception of Tasks that use Host networking mode) have separate networking namespaces. This means each task has a separate network interface with a separate IP address. They also have separate loopback interfaces that do not communicate with one another. Since they don't share a network namespace, they cannot communicate via "localhost" as most people think of it (i.e., via the lo0 interface), even if they reside on the same EC2 instance.

For tasks that use Bridge networking, the EC2 instance's Elastic Network Interface provides the ingress point. Ingress to ECS tasks running with bridge network is permitted by allowing traffic into the instance itself on the proper ports via the instance ENI's Security Groups. If a Task on Instance A initiates a direct connection to another Task running on Instance A running in bridge mode, then the traffic does not leave the instance, and so a Security Group rule allowing ingress will not be needed. But if a Task running on Instance A initiates a connection to a Task running on Instance B in bridge mode, then the Security Group configuration for Instance B's ENI must permit the traffic.

For tasks that use AWSVPC networking, each Task is assigned its own Elastic Network Interface with its own AWS VPC IP address. Each Task's ENI and IP address is completely separate from that of the EC2 instance itself. Task-to-task communication requires setting up the appropriate Security Groups on each interface and allowing ingress traffic as appropriate. This is true even if the traffic is destined to a Task on the same EC2 instance.

AWS
EXPERT
answered 2 years ago
profile picture
EXPERT
reviewed 9 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions