Q17

What security measures must be put in place when operating self-hosted runners?

Q: What security measures must be put in place when operating self-hosted runners?

> * **Never use self-hosted runners for public repositories**: Fork pull requests can run arbitrary code on your private servers (remote code execution). * **Use Ephemeral Runners**: Configure runners to register, execute exactly one job, and automatically deregister and self-destruct (using transient containers or auto-scaling groups). * **Network Isolation**: Place runners in private subnets with no public inbound rules; allow outbound HTTPS connections to GitHub endpoints only. * *

💬Answer

Never use self-hosted runners for public repositories: Fork pull requests can run arbitrary code on your private servers (remote code execution).
Use Ephemeral Runners: Configure runners to register, execute exactly one job, and automatically deregister and self-destruct (using transient containers or auto-scaling groups).
Network Isolation: Place runners in private subnets with no public inbound rules; allow outbound HTTPS connections to GitHub endpoints only.
Non-Root Execution: Run the runner agent process using a non-privileged system user (USER runner).

Related GitHub Actions Questions

View All GitHub ActionsQuestions →

What is GitHub Actions, and how does it process workflows under the hood?

Can you list and explain the key architectural components of GitHub Actions?

How do you configure workflow triggers, and what is the syntax for defining manual execution parameters?

What is a matrix strategy in GitHub Actions, and in what scenarios would you use it?

Created by

Apurv Gujjar

DevOps & Cloud Engineer

Specialized in:DevOpsAWSGCPKubernetesTerraformDocker

View Portfolio