Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider implementing an egress proxy for https #256

Open
jamesbursa opened this issue Apr 18, 2023 · 0 comments
Open

Consider implementing an egress proxy for https #256

jamesbursa opened this issue Apr 18, 2023 · 0 comments
Labels
domain: security Security or compliance issue

Comments

@jamesbursa
Copy link
Contributor

The application will typically need to make egress connections to various services, e.g. ECR, New Relic, Splunk, or other 3rd party services, and other system-to-system APIs.

Usually it's impractical to limit these using IP address allow lists, due to CDNs or other ways that IPs frequently change or are shared.

Instead, consider implementing an egress proxy. This could be an instance of squid (or something else) that runs in Fargate. It would be configured with an allow list of domain names. Unexpected requests would be denied and alert an admin.

The application would have a security group only allow egress to the proxy, and all libraries would be configured to use it (e.g. https_proxy env variable).

See Providing controlled internet access through centralised proxy servers using AWS Fargate and PrivateLink | Networking & Content Delivery for an example.

Instead of squid, it might be possible to use AWS Network Firewall. See Migrating from Squid Web Proxy to AWS Network Firewall | Networking & Content Delivery

@jamesbursa jamesbursa added the domain: security Security or compliance issue label Apr 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain: security Security or compliance issue
Projects
None yet
Development

No branches or pull requests

1 participant