You Shall Not Pass (tls): Filtering GitHub to One Org Path with AWS Network Firewall
A client wanted private-subnet EC2s to reach github.com/their-org but nothing else on github.com. I built a Terraform sandbox to test whether AWS Network Firewall could actually enforce it. It can, but only after three non-obvious fixes: dropping the blanket pass-tls rule that leaks every path, using flowbits to allow the response direction for the tagged org-path request, and pinning clients to HTTP/1.1 because the firewall's http.uri keyword ignores HTTP/2 (which github speaks by default). Then I tested the real git workflow: clone, pull, and push to the approved org all work (including a 184 MB clone, which stays entirely on github.com and never redirects to a CDN), while what actually breaks is narrower than expected: Git LFS, release-asset, and raw-file downloads from githubusercontent.com, plus SSH. This post walks through the architecture, each fix with the error that exposed it, the full test matrix, and why the working demo still isn't the right control for 'only our org' (the HTTP/1.1 pin is client-side, githubusercontent.com can't be org-scoped, SSH must be blocked outright). The robust answer is GitHub Enterprise Managed Users with SAML SSO.
READ ARTICLE