Security group inbound rules are too lax

[mx-psi]

The current security group setup under the terraform/setup folder has inbound rules with a CIDR group 0.0.0.0/0. This is not allowed under certain security group policies because it allows an arbitrary computer to connect to the instance, and it is sometimes considered a bad security practice.

It would be useful to either change the default behavior or have an option to make these rules more restrictive. In particular, I believe the minimal inbound rules would need to be to

1. allow other instances within the same security group to connect to each other and
2. allow the IP from the machine who is doing the setup to connect via SSH, so that Terraform can provision the machines correctly.

[wyTrivail]

@mx-psi Thank you for raising this concern and the suggestion! Yes it's indeed a security problem which i have also been considering to limit the access of those ports.

I briefly looped through the ports, below are the details of what we can do.

• port 22/5985: probably fine to leave it public as we keep ssh key locally.
• port 80/8080: it's used in end to end test validation where github workflow calls the api under 80 and generate the trace or get the validation result, we have to open it to public or we can find the ip range of github workflow instance. For people want to run the testing framework locally like datadog, we can have a option to configure the machine ip(thx for the suggestion :) )
• port 443: it's used in mock server to receive request from collector, we can limit it to the internal ip range under the vpc.
• port 55671/55680/55690. both are ports in collector, we can limit to the internal ip range under the vpc.
• port 4567: this could be limited to internal ip range of the vpc as it's just the sample app real port under the load balancer.
• port 3389, it can be removed as it's not used any more.
• port 2049/0, it's used for EFS in ecs test, which could be limited to internal ip range of the vpc.

I'm marking this issue as an enhancement so that we can track it.

[mx-psi]

Glad to see that this is being considered, and thank you very much for providing the uses of the different ports, this is helpful to double check that I was doing the correct thing here :)

port 22/5985: probably fine to leave it public as we keep ssh key locally

I agree there is no security concern here, but for us it would still be helpful to have some sort of option to provide an IP: if you set a rule with a 0.0.0.0/0 CIDR block in our AWS environments it will get automaticallly deleted (likely related to AWS Firewall Manager), so you have to set it up manually afterwards.

[wyTrivail]

@mx-psi Thx for pointing that out!

Yes, we can add an option to configure the allowed ips for ports(22, 5985, 80, 8080) so that the people configure their own machine ip or gateway ips. We probably need to support a ip range because most of the company's gateway is a range of ip.