Re:We Executed a Critical Supply Chain Attack on PyTorch
by jackwilsdon on Sunday January 14, 2024 @04:19PM
(#38994540)
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/...
Re:We Executed a Critical Supply Chain Attack on PyTorch
by gz5 on Sunday January 14, 2024 @05:34PM
(#38995126)
there are 3rd party foss options (1):
1. ephemeral + zero implicit trust (2) https://blog.openziti.io/my-intern-assignment-call-a-dark-we...
2. zero implicit trust: 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
Re:We Executed a Critical Supply Chain Attack on PyTorch
by crohr on Monday January 15, 2024 @03:07AM
(#38998456)
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
Re:We Executed a Critical Supply Chain Attack on PyTorch
by withinboredom on Tuesday January 16, 2024 @12:24PM
(#39015944)
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.
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.