A cluster-wide default egress policy is a baseline rule set that restricts outbound network calls from all workflow runs on a self-hosted runner cluster. It provides broad containment without changing every workflow file, while still allowing more specific workflow-level allow lists to override the default when necessary.
What the policy actually does at cluster scope
A cluster-wide default egress policy sets a baseline outbound network posture for every workflow run on a self-hosted runner cluster. Instead of relying on each workflow author to remember outbound restrictions, it creates a default containment layer that applies unless a narrower allow list is explicitly needed.
The practical value is consistency. A single default policy can reduce accidental internet access, stop low-value telemetry or update traffic from becoming an unnoticed path out of the cluster, and give security teams a uniform starting point for review. It is most useful where many workflows share the same execution environment and the security team wants one control point rather than dozens of file-level exceptions.
How it differs from workflow-level allow lists
The key design choice is precedence. The cluster-wide default sets the floor, while workflow-level rules can make targeted exceptions when a job genuinely needs a destination. That makes the policy model flexible, but it also means the default must be written carefully so it does not become either too permissive to matter or so restrictive that teams bypass it through ad hoc exceptions.
This pattern works best when the default captures the normal case and the workflow-specific allow list captures the exception case. In practice, that means the cluster policy should be understandable to platform owners, while individual workflow allowances should be narrowly scoped, reviewable, and tied to a real business or build dependency.
Why it matters for containment and trust boundaries
Outbound control is one of the cleanest ways to shrink the blast radius of a compromised workflow or runner. If a job is malicious, tampered with, or simply misconfigured, restrictive egress can limit where it can send data, what services it can reach, and how far an attacker can move after gaining execution on the runner.
For a shared cluster, the trust boundary is the cluster itself, not the individual repository. That makes default egress policy a platform-level safeguard, similar in spirit to safe baselines in other secure-by-default designs. It becomes especially important where runners process secrets, build artifacts, deployment credentials, or other high-value materials that should not be able to reach arbitrary external endpoints.
Operational trade-offs and governance model
There is always a balance between protection and developer friction. A default egress policy that is too broad provides little real containment, while one that is too strict can break package downloads, API calls, artifact publishing, or internal service access. The control only works when teams know which destinations are expected and who approves changes to the baseline.
For that reason, the policy should be treated as a governed platform control, not a one-time network rule. Versioning, exception tracking, and periodic review matter because outbound dependencies change over time. The goal is to keep the default narrow enough to limit exposure, but stable enough that workflow teams can rely on it.
Risk and Threat Considerations
Default egress policy reduces the damage that follows runner compromise, but it does not eliminate the risk of data exfiltration or command-and-control traffic if permitted destinations are too broad. It is also vulnerable to policy drift, where exceptions accumulate until the baseline no longer meaningfully constrains outbound access.
Failure mechanism: A compromised or overly permissive workflow can use allowed egress paths to leak secrets, download payloads, or pivot to internal services. If the cluster baseline is weak, attackers can abuse the shared runner environment as a launch point for broader abuse.
Impact: The result can be credential exposure, supply-chain compromise, unauthorized data transfer, and loss of confidence in the runner cluster as a trusted execution boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Cluster egress defaults are a secure baseline configuration for shared runner infrastructure. |
| CIS 6 — Access Control Management | Workflow exceptions require controlled approval and periodic cleanup to avoid policy drift. | |
| Recommendation — Enforce hardened default egress settings and review exceptions as part of secure configuration management. Track and remove egress exceptions with disciplined access control management. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Outbound restrictions on runners constrain what workflow executions can access externally. |
| Recommendation — Apply access control to restrict outbound paths from runner clusters to approved destinations. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection | Default egress policy creates an enforceable network boundary around shared execution workloads. |
| Recommendation — Use boundary protection to limit cluster egress and permit only explicitly required destinations. | ||
Practitioner Guidance
Why practitioners should care: The control is most valuable when many teams share runners and the organisation wants a single enforceable outbound baseline. In that setting, it is easier to govern one cluster policy than to audit dozens of workflow files for hidden network dependencies.
What to watch for: The most common failure mode is exception sprawl. If allow lists become broad, undocumented, or difficult to review, the default policy stops functioning as a real containment mechanism and becomes only a nominal guardrail.
Related resources from NHI Mgmt Group
- When should organisations use destination-specific policy instead of proxy-wide rules?
- What breaks when birthright access is treated as a company-wide default instead of a scoped baseline?
- Why do event-streaming platforms need policy enforcement when many producers publish to the same cluster?
- What is the difference between cluster-wide mesh visibility and namespace-scoped mesh access?
