Runner Group

What Runner Groups Do in CI

Runner groups are administrative boundaries for automation capacity. They let teams decide which jobs can use which runners, so build, test, and deployment work lands on the right execution pool rather than on any available machine.

That control matters because runners often sit near high-value secrets, source code, artifact stores, and deployment targets. A runner group is therefore not just an organiser, it is a policy boundary that shapes where automation is allowed to execute and what it can reach.

How Runner Groups Shape Trust Boundaries

In practice, runner groups are used to separate trust zones. A public repository, a sensitive internal repository, and a production deployment workflow should not necessarily share the same runners, because the same execution host may inherit different levels of risk depending on the jobs it runs.

This is why runner groups often sit alongside repository, organisation, or environment policy. The grouping helps enforce that a job can only use runners that match the intended security posture, rather than letting workflow authors implicitly inherit broader infrastructure access.

Why Runner Groups Affect Access and Isolation

Runner groups influence more than scheduling. They affect which automation paths can reach secrets, networks, and privileged internal services, especially when runners are self-hosted or segmented by environment. A permissive grouping model can quietly collapse isolation between low-trust and high-trust workloads.

Used well, runner groups support least privilege for automation by narrowing the set of executors a job can consume. Used poorly, they can create a false sense of separation if the runners themselves are overprivileged, reused across unrelated projects, or reachable from workflows that should not share execution context.

Common Failure Modes in Runner Group Design

The main failure mode is treating runner groups as a naming convenience instead of a control. If grouping rules are too broad, a compromised workflow can land on a runner that has access to secrets, internal network paths, or deployment credentials that were meant for a different trust zone.

Another common mistake is assuming that isolation exists because jobs are “labelled” for a runner group. The real boundary is the combination of group membership, runner hardening, secret scoping, and who can assign or reassign jobs to that group.

Risk and Threat Considerations

Runner groups create a real security boundary only when the runners behind them are tightly scoped. If access is too broad, an attacker who gains control of a lower-trust job can use the automation path to reach secrets, internal services, or downstream deployment environments that were meant to stay separate.

Failure mechanism: Weak group policy, shared runners, or overly permissive job routing let untrusted or less-trusted workflows execute in a higher-trust context, which can expose credentials, metadata, and internal network reachability.

Impact: The result can be secret theft, lateral movement through CI infrastructure, unauthorized deployments, or compromise of multiple repositories and environments through one shared execution path.

Practitioner Guidance

Why practitioners should care: Runner groups are one of the simplest places to enforce trust separation in CI, but they only work when the group policy matches the sensitivity of the jobs using it. OWASP CI/CD Top 10 CICD-SEC-5 Insufficient PBAC Guide is a useful reference when you are aligning runner access with least privilege, scoped secrets, and isolated execution.

What to watch for: Review runner group design whenever a workflow can reach production credentials, internal network resources, or environment-specific secrets. The key question is whether the group boundary is actually preventing cross-trust reuse, or merely documenting it.

Related resources from NHI Mgmt Group

• Who should be accountable for stale service accounts and nested group access?
• What do IAM teams get wrong about group-based permissions?
• How should teams reduce permission debt in group-based access models?
• What should organisations do when group management becomes unmanageable?