TL;DR: Blacksmith describes a transparent proxy that reroutes GitHub traffic through Tailscale Services and Squid when ISP degradation stalls CI jobs, with no customer code changes and traffic limited to GitHub endpoints. The architecture shows how routing resilience, authenticated service access, and least-privilege network paths increasingly intersect in modern platform operations.
At a glance
What this is: This is a blog post about using a transparent proxy to keep GitHub-connected CI jobs running during ISP degradation, with traffic interception limited to GitHub endpoints.
Why it matters: It matters because platform and IAM teams increasingly have to govern not just who or what can connect, but which fallback paths remain authenticated, scoped, and safe when primary routing fails.
Context
Routing resilience is the ability to keep critical traffic flowing when an upstream network path degrades or becomes unreliable. In this case, the operational problem was not a GitHub outage or a local application defect, but an in-between failure in ISP routing that stalled CI jobs touching GitHub services.
The governance gap is that conventional controls often assume the network path stays stable once access is permitted. For modern CI and service-to-service workflows, that assumption breaks quickly, because identity, service reachability, and transport path all become part of the same trust boundary.
The identity angle is real even though the primary issue is network resilience: the fallback path has to preserve authenticated access, restrict reachability to the intended service, and avoid broadening exposure while traffic is redirected.
Key questions
Q: How should teams design failover for service-to-service traffic without overexposing the network?
A: Treat failover as a scoped access control, not just a routing trick. Limit the fallback to known destinations, require authenticated service membership for the alternate path, and keep non-target traffic on the default route. That preserves resilience while preventing a temporary workaround from becoming a permanent trust expansion.
Q: Why do authenticated service boundaries matter when routing is degraded?
A: Because routing failure often tempts teams to add broad connectivity exceptions that outlive the incident. Authenticated service boundaries keep the recovery path tied to approved workloads and reduce the chance that a temporary proxy becomes an always-open ingress point.
Q: What fails when a fallback proxy is not destination-scoped?
A: The recovery control stops being a resilience mechanism and becomes a general network bypass. That increases blast radius, complicates auditing, and can expose unrelated services to traffic they were never meant to handle.
Q: Should organisations use static proxy endpoints or membership-based services for recovery traffic?
A: Membership-based services are usually easier to govern because access is tied to approved participants rather than a public address. Static endpoints can work, but they usually demand more compensating controls and create more pressure to widen network exposure during incidents.
Technical breakdown
How transparent proxying preserves GitHub-bound traffic
Transparent proxying intercepts packets before the application knows the path has changed. In this design, traffic destined for GitHub is rewritten at the kernel level, then handed to a proxy process that recovers the original destination and opens an upstream tunnel. That keeps GitHub Actions and similar workflows unchanged while the network path is substituted underneath them. The key technical value is that the application protocol stays intact while routing is altered, so recovery can happen without customer code changes or endpoint reconfiguration.
Practical implication: if you depend on transparent failover, validate that interception preserves the original destination and does not break TLS or application semantics.
Why service scoping matters more than generic network failover
A fallback path is only safe if it is constrained to the exact traffic class that needs rescue. Here, only GitHub-bound requests were intercepted, while all other traffic stayed on the normal path. That selective scope reduces operational blast radius and avoids turning a resilience control into a broad man-in-the-middle pattern. In identity terms, this is the difference between controlled service access and an overbroad network exception: the fallback must authenticate the intended service and exclude everything else.
Practical implication: enforce destination-based scoping so failover controls cannot become a general-purpose proxy for unrelated traffic.
How authenticated service access replaces brittle static network exposure
The proxy pool was made reachable through a Tailscale Service rather than by exposing public IPs or managing a conventional load balancer. That means the service has membership-based access, health validation, and encrypted transport built into the connection path. The security shift is important: resilience no longer depends on punching holes in security groups or publishing a static endpoint. Instead, access is mediated through an authenticated service boundary, which is closer to modern workload identity than to legacy network trust.
Practical implication: prefer authenticated service reachability over exposed proxy endpoints when designing recovery paths for critical third-party dependencies.
NHI Mgmt Group analysis
Routing resilience is now an identity problem as much as a network problem. When critical workloads fail over to an alternate path, the question is no longer only whether packets arrive. The real governance issue is whether the fallback path preserves authentication, scope, and least exposure while it does so. For CI and other machine-driven workflows, service access controls and routing controls have converged, and practitioners should treat them as one operating boundary.
Selective interception is the right pattern for fallback networking. A resilience control that touches every destination turns into an availability risk of its own, and often an access risk as well. Limiting failover to known GitHub endpoints keeps the control comprehensible, testable, and auditable. This is the kind of constrained design that identity and platform teams should prefer when a recovery path must exist but broad network trust cannot be justified.
Authenticated service reachability is becoming the modern replacement for static proxy exposure. Publishing a fixed IP and opening network paths creates unnecessary permanence, especially for infrastructure that only needs to exist during degraded conditions. Membership-based service access changes the governance model: the endpoint remains reachable only to authorised participants, not to the public internet. That aligns resilience design with NHI and workload access principles, where controlled reachability matters as much as raw connectivity.
Ephemeral recovery paths need the same governance discipline as primary paths. Teams often overfocus on the steady state and underdesign the fallback state, but failures expose the real trust assumptions. If the failover proxy is less controlled than the main path, resilience becomes a hidden privilege expansion. Practitioners should treat recovery networking as part of access governance, not as an emergency exception outside it.
What this signals
The bigger lesson is that failover design now sits inside identity governance, not outside it. If the recovery path cannot prove who or what is allowed to use it, the organisation has not really solved resilience. It has only moved the trust problem to a different layer.
Routing trust gap: the hidden failure mode is assuming that a temporary network bypass can remain safe without explicit service authentication and destination scoping. Practitioners should design fallback paths so the recovery plane is as tightly governed as the primary plane.
For practitioners
- Define destination-scoped failover rules Limit any transparent proxy or reroute mechanism to a fixed allowlist of critical destinations so fallback traffic cannot expand beyond the intended service boundary.
- Authenticate the recovery endpoint Require membership-based service access for alternate network paths so the recovery plane is reachable only by approved workloads and hosts.
- Test failover before the network degrades Load test the alternate path under realistic CI traffic so you can verify that job completion, proxy health, and destination matching all hold during an actual routing event.
- Separate recovery access from normal routing Keep the primary network path unchanged for non-GitHub traffic and avoid turning the fallback control into a broad-purpose proxy for unrelated services.
Key takeaways
- Routing resilience for CI is no longer just an infrastructure concern because fallback paths can widen trust if they are not tightly scoped.
- The article shows that selective interception and authenticated service reachability can preserve availability without changing customer workflows.
- Practitioners should govern recovery networking as part of access control, with allowlists, membership checks, and load testing before a degradation event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CSA Cloud Controls Matrix, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The fallback path relies on controlled service reachability and authenticated access. |
| Recommendation — Apply IAM controls to ensure only approved workloads can reach recovery services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Destination-scoped proxying is an authorisation problem as much as a routing problem. |
| Recommendation — Limit recovery-path entitlements so only intended traffic can traverse the alternate route. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | The alternate service path is reached by workloads rather than human users. |
| Recommendation — Use IA-9 to govern how service identities authenticate to the fallback path. | ||
| CIS Controls v8 | CIS-5 — Account Management | The proxy service depends on tightly managed service membership and reachability. |
| Recommendation — Maintain tight account and service membership control for any recovery-plane endpoint. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | Overbroad failover paths can expand what traffic can discover and reach across the environment. |
| Recommendation — Map any broadened recovery route to discovery and lateral-movement risk in your detections. | ||
Key terms
- Transparent proxy: A transparent proxy intercepts traffic without requiring the client to change how it connects. In this design, the network rewrites traffic destined for a chosen service and forwards it through an alternate path while preserving the original destination and user experience.
- Destination Scoping: Destination scoping limits a control to specific endpoints, IP ranges, or service classes instead of applying it broadly to all traffic. In resilience design, it prevents a temporary workaround from becoming an uncontrolled network bypass and keeps the fallback path auditable.
- Authenticated Service Reachability: Authenticated service reachability means a service is accessible only to approved identities or managed members, rather than to anyone who can discover its address. It is a practical control for recovery paths because it couples availability with explicit access governance.
- Routing Resilience: Routing resilience is the ability of network paths to remain reliable under load, fault, or attack. For identity programmes, it determines whether access journeys stay reachable and consistent enough for authentication and authorisation controls to function as intended.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in practical terms. It helps security and platform practitioners align access control with the systems that depend on it.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org