How do I incorporate a forward web proxy in the gruntwork RA
Our customers want to manage/block/allow outbound web traffic via squid (or similar) forward web proxy. I can think of two primary ways to do this: 1. Add a squid EC2 node as a _transparent forward/outbound proxy_ - Add a squid EC2 node. Use a persistent ENI, e.g. one provided by the [ASG server-group module](https://github.com/gruntwork-io/terraform-aws-asg/tree/main/modules/server-group) - update the relevant route table(s) to route 0.0.0.0 traffic to this ENI - add a route table for this node that routes 0.0.0.0 traffic to the RA NAT instance - no internal node/app configuration needed 2. Add a squid EC2 node as an _explicit forward/outbound proxy_ - Add a squid EC2 node. Use a persistent ENI, e.g. one provided by the [ASG server-group module](https://github.com/gruntwork-io/terraform-aws-asg/tree/main/modules/server-group) - set the proxy URL environment vars `http_proxy` and `https_proxy` for _all the Linux Ec2 instances in the architecture_ to point to the squid interface/port - configure internal apps to use the same proxy URL - no route table work Method 2 is easier to implement but is a "weak/soft" control on outbound web traffic. (A malicious or misconfigured app could just communicate outbound without using the proxy. Method 1 would be much stronger but I would expect the gruntwork [vpc module](https://github.com/gruntwork-io/terraform-aws-vpc/tree/main/modules/vpc-app) to "fight" over the routes in the route tables. How have gruntwork customers provided this kind of outbound traffic inspection/filtering? --- <ins datetime="2022-12-30T13:01:32Z"> <p><a href="https://support.gruntwork.io/hc/requests/109753">Tracked in ticket #109753</a></p> </ins>
Hi @hammondr, we don’t currently have a pre-made module to address this kind of proxy. An option would be using AWS Network Firewall, and we had started work to add support for it in our vpc module (https://github.com/gruntwork-io/terraform-aws-vpc/pull/210). However, this PR is currently paused while we scale our team, but maybe the progress made so far can offer some insight into how one could adopt this kind of solution? Regarding your options, I would lean torwards the first approach. About the `vpc_module` “fighting” this setup, you might have to disable some features in it and create some resources externally to the module, but it could work. For example, you could disable the creation of the internet gateway through the variable `var.create_igw` or some flags involved in the creation of the routes that could conflict with your intended setup. For example: https://github.com/gruntwork-io/terraform-aws-vpc/blob/main/modules/vpc-app/main.tf#L404. Concerning more general solutions for Squid proxy, this post has some interesting suggestions, such as putting the Squid node in an ASG of size 1: https://aws.amazon.com/blogs/security/how-to-add-dns-filtering-to-your-nat-instance-with-squid/