What I did
The ECS stack includes an ingress rule to allow LB to reach the tasks.
However, the ingress was added inside the Docker network security group, exposing all containers to requests on this port from 0.0.0.0/0.
This means tasks that don't have exposed ports on the compose spec, and possibly contain unprotected sensitive endpoints, were exposed to outside access (I personally had a NodeJS Express server getting /.env hit by random scrapers).
We now do the following:
Do not touch the network security group. It only contains one rule, allowing cross-task communication inside the network.
Create a per-service "LB" security group, attached to the load balancer, exposing the published ports for outside access
Create a per-service "Service" security group, attaching it to the services' tasks, allowing access from the LB on the specified ports
Why is this better
Other sensitive tasks in the same network as port-exposing ones remain unaccessible, except for other tasks on the network
The port-exposing tasks are only accessible by the LB (not outside access)
The LB is exposed to the outside, and in turn can only access the port-exposing tasks (and not other tasks on the same networks)
Related issue
Solves #1783
Manual testing
A bit long:
Modify the slightly-complex stack to have a real VPC and subnets, then create it:
set -eu
cd ecs
go test . -update
perl -pe 's/vpc-123/vpc-XXXXXXX/ ; s/subnet1/subnet-YYYYY/ ; s/subnet2/subnet-ZZZZZ' -i testdata/slightly-complex-cloudformation-conversion.golden
aws us-east-1 cloudformation delete-stack --stack-name slightly-complex
aws cloudformation create-stack --stack-name slighlty-complex --template-body file://$(realpath testdata/slightly-complex-cloudformation-conversion.golden) --capabilities CAPABILITY_IAM
What I did The ECS stack includes an ingress rule to allow LB to reach the tasks. However, the ingress was added inside the Docker network security group, exposing all containers to requests on this port from 0.0.0.0/0. This means tasks that don't have exposed ports on the compose spec, and possibly contain unprotected sensitive endpoints, were exposed to outside access (I personally had a NodeJS Express server getting
/.env
hit by random scrapers).We now do the following:
Why is this better
Related issue
Solves #1783
Manual testing A bit long:
Modify the slightly-complex stack to have a real VPC and subnets, then create it:
Reminder, the Compose looks like this:
Both tasks have a public IP, but they're not accessible from the outside:![image](https://user-images.githubusercontent.com/7194491/212048308-2b66f2f1-6f4b-4d2e-af61-b0394a858aef.png)
However, the LB is accessible and responding:
(not mandatory) A picture of a cute animal, if possible in relation with what you did Claro![image](https://user-images.githubusercontent.com/7194491/212048901-45e8eed2-b6f3-4170-a190-bf4fb896d497.png)