Enable permissions to modify the default route table for operations s…

[FLeiXiuS]

🗣 Description

VPC peering establishes a secure, private network connection by utilizing private IP addresses, connecting one or more Virtual Private Clouds (VPCs). To ensure the seamless peering of VPCs and the successful routing of data across the operations and private subnets, specific permissions need to be configured.

Here are the required permissions:

1. Modify Default Operations Routing Table: It's necessary to have the permission to make modifications to the default operations routing table. This adjustment involves adding routes for the newly peered networks. This step ensures that traffic can be correctly directed to the VPC networks that have been peered.
2. Associate Operations Subnet with Operations Route Table: It might seem logical that the default operations subnet should be automatically associated with the default operations route table; however, this was not the case. In the context of VPC peering, this association is not automatically assumed either. Although AWS might consider this association as default behavior, it's insufficient for the requirements of VPC peering. Explicitly associating the operations subnet with a route table becomes vital in enabling routing to the peered networks.

💭 Context

I currently support the CISA VM RTA team and our infrastructure deployments within the COOL requires redirectors and other services in external Virtual Private Clouds (VPCs) with various regions within AWS. Traffic between the operations subnet and our redirectors in external VPCs are visible to the internet over public IP space. Our goal is to achieve internal routing of traffic between trusted infrastructure within AWS. This necessitates the implementation of VPC peering and ensuring that the appropriate permissions are in place for seamless and secure routing through the RTA environment.

[dav3r]

FYI, I worked with @FLeiXiuS on this during the testing stages. Now we want to get more eyes and perspectives on this PR.

[FLeiXiuS]

I have a few minor changes to request.

I also have one comment. If your VPC peering involves more than two VPCs then it usually makes more sense to use a Transit Gateway versus VPC peering. This is because the Transit Gateway centralizes the rules that determine which VPCs can communicate, and you need only create N Transit Gateway Attachments versus ~N^2 VPC peering resources. This advice may not apply in your use case, but I mention it just in case it's helpful.

We don't necessarily need the VPC"s to route to each other in a star topology. We're mostly interested in the operations VPC communicating with the external VPCs versus ALL of the VPCs being able to route to one another. I suppose we could segment with SGs. Curious to hear your thoughts.

[dav3r]

Explicitly associating the operations subnet with a route table becomes vital in enabling routing to the peered networks.

@jsf9k Can you think of any reasons why it would be a problem if we explicitly associated that default route table with the Operations subnet? If we do that, then we wouldn't need to add the permission to allow associating/disassociating route tables from the Operations subnet, at least not for the use case @FLeiXiuS has expressed.

[dav3r]

Since we already allow the Terraformer instance to disassociate the default routing table and associate a new one, I don't think there's any further risk from a security standpoint with allowing the Terraformer to modify routes in the default routing table. @cisagov/team-ois (or anyone else) if you think otherwise, now is a great time to speak up.

[jsf9k]

Since we already allow the Terraformer instance to disassociate the default routing table and associate a new one, I don't think there's any further risk from a security standpoint with allowing the Terraformer to modify routes in the default routing table. @cisagov/team-ois (or anyone else) if you think otherwise, now is a great time to speak up.

If it were up to me then I'd prefer that the default routing table be left alone. This is because new subnets not explicitly assigned a routing table will be assigned the default one. I'd prefer that folks who want to modify the default routing table instead create a new one and explicitly associate it with the subnets they care about.

That said, I can live with folks modifying the default routing table if there is a reason to prefer that approach.

[dav3r]

Since we already allow the Terraformer instance to disassociate the default routing table and associate a new one, I don't think there's any further risk from a security standpoint with allowing the Terraformer to modify routes in the default routing table. @cisagov/team-ois (or anyone else) if you think otherwise, now is a great time to speak up.

If it were up to me then I'd prefer that the default routing table be left alone. This is because new subnets not explicitly assigned a routing table will be assigned the default one. I'd prefer that folks who want to modify the default routing table instead create a new one and explicitly associate it with the subnets they care about.

That said, I can live with folks modifying the default routing table if there is a reason to prefer that approach.

@FLeiXiuS Can you please explain why you prefer to modify the default routing table rather than use a new routing table of your own creation?

[FLeiXiuS]

Since we already allow the Terraformer instance to disassociate the default routing table and associate a new one, I don't think there's any further risk from a security standpoint with allowing the Terraformer to modify routes in the default routing table. @cisagov/team-ois (or anyone else) if you think otherwise, now is a great time to speak up.

If it were up to me then I'd prefer that the default routing table be left alone. This is because new subnets not explicitly assigned a routing table will be assigned the default one. I'd prefer that folks who want to modify the default routing table instead create a new one and explicitly associate it with the subnets they care about. That said, I can live with folks modifying the default routing table if there is a reason to prefer that approach.

@FLeiXiuS Can you please explain why you prefer to modify the default routing table rather than use a new routing table of your own creation?

Certainly. I was unable to create another route table for the operations subnet and have that routeable without associating it to the subnet itself. At that point, the default route table with the transit gateway and the IGW would not be included in this route table.

I could duplicate these routes in the new table, but at that point its the same effect to just modify the original route table.