Discover RDS security group picker is confusing

[r0mant]

The security group selector works but can be fairly confusing, especially for a new user. Specifically, if I have multiple security groups, how do I know which one to pick?

I wonder what we can do to streamline this step more - can we create a security group ourselves, as a part of the script user runs in CloudShell? Or highlight the "recommended" sec. groups e.g. the one in which the database itself is deployed?

[GavinFrazar]

There's also no "refresh" button, which means if you get to this page and realize you need to create a new security group, then you have to restart the entire enrollment flow again to select your new security group.

can we create a security group ourselves, as a part of the script user runs in CloudShell

If we do that, then they will likely need to add that security group to their databases' security group inbound rules. We could modify all those security groups for them as well in the script.

highlight the "recommended" sec. groups e.g. the one in which the database itself is deployed?

I wouldn't recommend deploying into the same security group as the databases because we need outbound allowed to 0.0.0.0 (to reach teleport cluster and reach our public ECR repo to pull the image), and being in the same security group doesn't grant access unless the security group allows inbound from itself.

Here are the network requirements:

1. the ECS task security group must allow outbound to reach their cluster and our public ECR repo to pull the image
2. the databases' security group(s) must allow inbound from the ECS task security group or from the ECS task subnet(s) CIDR blocks
3. the ECS task subnets must all have a route to either a NAT gateway or an Internet Gateway.
4. the ECS task subnets must either be the same subnet as the databases or have a route to the database subnet(s).

and here's what we could do to address each:

1. ask the user to select a security group or have a button to create a security group with allowed outbound to 0.0.0.0/0.
2. show all database security groups that do not have an allowed inbound rule for the selected security group. Ask them to either update that themselves, or have a button to do it for them. They will probably have their database security groups in Terraform and will want to change it themselves.
3. add a column "internet access" to the subnet selector table and for each subnet show (✅ or ❌ or ❓) based on routing table analysis.
4. add a column "route to database subnets" to the subnet selector table and likewise indicate yes/no/unknown.

[greedy52]

I believe you can assign multiple security groups though. What if we create a security group for outbound, and at the same time assign the same security group the db uses if necessary?

[GavinFrazar]

We could check the database security groups to see if they allow inbound from themselves.

We discussed this in 1x1, but I think we could consolidate actions 3 and 4 into a single column: "Database Connectivity" (yes/no/unknown) and just show details on hover, e.g.

• ❌ selected security group "sg-123" does not allow outbound traffic
• ✅ database security group(s) allow inbound from a selected security group
• ✅ selected subnet(s) have a route for outbound internet traffic
• ❌ subnet-X has no route to database-Y, update the routing table associated with subnet-X or select a different subnet.