3 ms·

Self-hosted runners is the way to go, IMHO. Especially if you have bare metal resources. I love how fast my builds are with 16 cores, and gobs of ram.

ethbr1 3y ago
What's the GitHub Actions tooling like for emphemeral self-hosted runners? Afaict, a huge portion of this attack came from persistence on the self-hosted runner. Absent that, they would have needed a container jailbreak as well, which substantially ups the difficulty. And if a repo is running <100 builds a day, spin up + kill container seems a small per-build price to pay for the additional security isolation.
- jackwilsdon 3y ago
  GitHub themselves don't seem to provide any mechanism to make runners ephemeral. It looks like all they allow you to do is flag a runner as ephemeral, meaning it will be de-registered once a job is completed - you need to write your own tooling to wipe it yourself (either via starting a whole new runner in a new environment and registering that or wiping the existing runner and re-registering it). https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#using-ephemeral-runners-for-autoscaling https://docs.github.com/en/actions/hosting-your-own-runners/...
  - gz5 3y ago
    there are 3rd party foss options (1): 1. ephemeral + zero implicit trust (2) https://blog.openziti.io/my-intern-assignment-call-a-dark-webhook-from-aws-lambda https://blog.openziti.io/my-intern-assignment-call-a-dark-we... 2. zero implicit trust: https://github.com/openziti/ziti-webhook-action https://github.com/openziti/ziti-webhook-action (1) disclosure, maintainer (2) zero implicit trust in this case = no open inbound ports on underlay; need to access via app-specific overlay which requires strong identity, authN, authZ
  - crohr 3y ago
    I've just made runs-on [1] for that purpose: self-hosted, ephemeral runners for GitHub Action workflows. Long-running self-hosted runners are simply too risky if your project is public. [1]: https://runs-on.com https://runs-on.com
- withinboredom 3y ago
  The default kubernetes implementation owned by github[1] assumes ephemeral runners by default. You can also specify what policies they should have using regular network policies provided by kubernetes. So, if you have a kubernetes cluster, that's the way to go. [1]: https://github.com/actions/actions-runner-controller https://github.com/actions/actions-runner-controller

ethbr1 3y ago

What's the GitHub Actions tooling like for emphemeral self-hosted runners? Afaict, a huge portion of this attack came from persistence on the self-hosted runner. Absent that, they would have needed a container jailbreak as well, which substantially ups the difficulty. And if a repo is running <100 builds a day, spin up + kill container seems a small per-build price to pay for the additional security isolation.

jackwilsdon 3y ago
GitHub themselves don't seem to provide any mechanism to make runners ephemeral. It looks like all they allow you to do is flag a runner as ephemeral, meaning it will be de-registered once a job is completed - you need to write your own tooling to wipe it yourself (either via starting a whole new runner in a new environment and registering that or wiping the existing runner and re-registering it). https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#using-ephemeral-runners-for-autoscaling https://docs.github.com/en/actions/hosting-your-own-runners/...
- gz5 3y ago
  there are 3rd party foss options (1): 1. ephemeral + zero implicit trust (2) https://blog.openziti.io/my-intern-assignment-call-a-dark-webhook-from-aws-lambda https://blog.openziti.io/my-intern-assignment-call-a-dark-we... 2. zero implicit trust: https://github.com/openziti/ziti-webhook-action https://github.com/openziti/ziti-webhook-action (1) disclosure, maintainer (2) zero implicit trust in this case = no open inbound ports on underlay; need to access via app-specific overlay which requires strong identity, authN, authZ
- crohr 3y ago
  I've just made runs-on [1] for that purpose: self-hosted, ephemeral runners for GitHub Action workflows. Long-running self-hosted runners are simply too risky if your project is public. [1]: https://runs-on.com https://runs-on.com
withinboredom 3y ago
The default kubernetes implementation owned by github[1] assumes ephemeral runners by default. You can also specify what policies they should have using regular network policies provided by kubernetes. So, if you have a kubernetes cluster, that's the way to go. [1]: https://github.com/actions/actions-runner-controller https://github.com/actions/actions-runner-controller