What is 'security hardening' for GitHub Actions self-hosted runners?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Hardening self-hosted runners is about limiting blast radius. Use ephemeral runners so each job starts clean. Run the runner service under a low-privilege account. Restrict network egress so a compromised job can't phone home. These aren't optional nice-to-haves — they're essential when running untrusted code.
Full explanation below image
Full Explanation
GitHub's security hardening guidance for self-hosted runners includes multiple defense-in-depth practices: (1) Ephemeral runners — use single-use, disposable runners (--ephemeral flag or JIT) to prevent job-to-job contamination. (2) Least privilege runner service account — run the runner service as a non-admin user with minimal filesystem and network permissions. (3) Network isolation — restrict outbound internet access; only allow required hosts (GitHub APIs, package registries). (4) No persistent secrets — don't store long-lived credentials on the runner; use OIDC or short-lived tokens. (5) Private repository restriction — ensure self-hosted runners are not used for public repository workflows (prevents malicious fork PRs). (6) Separate runner pools per environment — production runners should not run PR validation workflows. (7) Regular OS patching — keep runner OS and software updated.