ECS Fargate terraform example causes problems with 1Password firewall

[philomory]

The example for deploying to ECS Fargate places the task in a public VPC subnet, which means, at least when using Fargate, it's not possible to ensure that outgoing traffic comes from a specific IP address or set of IP addresses - if the task was deployed to a private subnet, then all outbound traffic to the Internet would come from the elastic IP address of NAT gateway. In a public subnet, a fargate service can have a public IP address (and indeed, the example configuration in this repository gives it one), but you have no control over what that IP address is, and as it is not an elastic IP address, it can change without warning.

For incoming traffic, this is not really a problem, as all incoming traffic goes through the load balancer, and not through the service's public IP address. But, outgoing traffic from the SCIM bridge (such as that going to 1password.com) has as its source IP address the public IP address of the service itself, when the service is deployed as shown in the example. However, 1Password recommends setting up a Firewall rule (within the 1Password admin policies) that blocks access from anonymous IP addresses such as from public cloud providers. This would be fine, if we could an explicit exception to the rule by explicitly allowing the IP address of the SCIM bridge, but of course, that won't work if the SCIM bridge doens't have a fixed IP address.

Anyway, all of that is a long-winded way of suggesting that the example deployment should probably place the SCIM bridge in a private subnet with a NAT gateway, to allow outbound traffic to come from a knowable (and thus allowlistable) IP address.

[ag-adampike]

Hey @philomory! Thanks for filing this issue and sharing those details.

That is indeed the case for all of our AWS deployment examples at the moment. They are purposefully minimal by design and aren't intended to cover all deployment scenarios. That helps us provide something minimal that should work "out-of-the-box" with any identity provider and allows implementers to customize or extend it to fit the requirements for their infra.

That said, we do include some common configuration options for convenience. Internally, we have discussed how and whether to provide this as an option for our AWS deployment examples, but haven't framed anything out just yet.

Some workarounds to consider until we do:

• Add an Allow rule for Cloud Providers in the 1Password firewall.
• Instead of public subnets, deploy in private subnets that have a route to a NAT Gateway (managed elsewhere or merged into a customized deployment).
• Use IPv6 with an egress-only internet gateway and add an Allow rule with the IPv6 subnet for your ECS service for SCIM bridge (no NAT Gateway needed!)