This would allow for an external runner orchestrator to spin up completely fresh envs for each job (assuming running as non-docker/exec mode), in firecracker/fargate/tart/etc..
A runner would accept one job, run it, then exit.
This would allow for an external runner orchestrator to spin up completely fresh envs for each job (assuming running as non-docker/exec mode), in firecracker/fargate/tart/etc..
Yeah, that could be one case. Where the orchestrator sees a job has come in and starts a new lambda run with a oneshot agent, and then when job is done agent will quit and lambda will stop.
> serverless runner?
Yeah, that could be one case. Where the orchestrator sees a job has come in and starts a new lambda run with a oneshot agent, and then when job is done agent will quit and lambda will stop.
Two act_runners can connect with the same token to Gitea Actions, while in GitHub Actions this is currently impossible due to session lock.
To reproduce execute act_runner daemon twice with the same configuration.
For example currently someone can craft a workflow file, which either
bind mount the runner config (container mode) This has been fixed
use the bind mounted docker socket to do the bind mount runner config anywhere in the step (container mode)
You are unaffected if the docker daemon and the act_runner has no shared folder containing .runner
Dind in the same container as act_runner is affected.
directly access the runner config (host mode)
Finally use the token to receive jobs outside of your infrastructure. All jobs sent to the duplicated instance get access to new job requests and it's secrets.
Only allow to connect one runner with the same token at a time can increase security and make it harder to use the token while the job is running.
Finally ephemeral runners would fix the hole, if Gitea Actions would never send a second job to the runner.
Two act_runners can connect with the same token to Gitea Actions, while in GitHub Actions this is currently impossible due to session lock.
To reproduce execute `act_runner daemon` twice with the same configuration.
For example currently someone can craft a workflow file, which either
- ~~bind mount the runner config (container mode)~~ This has been fixed
- use the bind mounted docker socket to do the bind mount runner config anywhere in the step (container mode)
You are unaffected if the docker daemon and the act_runner has no shared folder containing .runner
Dind in the same container as act_runner is affected.
- directly access the runner config (host mode)
Finally use the token to receive jobs outside of your infrastructure. All jobs sent to the duplicated instance get access to new job requests and it's secrets.
Only allow to connect one runner with the same token at a time can increase security and make it harder to use the token while the job is running.
Finally ephemeral runners would fix the hole, if Gitea Actions would never send a second job to the runner.
Only allow to connect one runner with the same token at a time can increase security and make it harder to use the token while the job is running.
This would be great to have. Along with ephemeral runners and a public API to generate short-lived, single-use runner registration tokens. It would allow us to create orchestration around spinning up/taring down runners.
For GitHub we wrote an auto-scaler that can spin up ephemeral self-hosted runner pools on potentially any IaaS, because we needed VMs/bare metal for runners (initially). I would love to try and add gitea as a platform along side GitHub and GitHub enterprise server.
> Only allow to connect one runner with the same token at a time can increase security and make it harder to use the token while the job is running.
This would be great to have. Along with ephemeral runners and a public API to generate short-lived, single-use runner registration tokens. It would allow us to create orchestration around spinning up/taring down runners.
For GitHub [we wrote an auto-scaler](https://github.com/cloudbase/garm) that can spin up ephemeral self-hosted runner pools on potentially any IaaS, because we needed VMs/bare metal for runners (initially). I would love to try and add `gitea` as a platform along side GitHub and GitHub enterprise server.
I would request to reopen this issue, because I'm not aware of single use runner registrations access tokens.
e.g. once the server sent a job, block the runner from fetching another one.
In GitHub Actions Ephemeral != run once.
Would solve security implications of host mode.
That in no case someone can fetch another job regardless how much the runner is exploited.
Otherwise I create a new issue and may look into enhancing the server side
I would request to reopen this issue, because I'm not aware of single use runner registrations access tokens.
e.g. once the server sent a job, block the runner from fetching another one.
In GitHub Actions Ephemeral != run once.
Would solve security implications of host mode.
That in no case someone can fetch another job regardless how much the runner is exploited.
Otherwise I create a new issue and may look into enhancing the server side
This would involve three source code repos and a protocol field addition
Created a technical proposal for server side here https://github.com/go-gitea/gitea/issues/32461 with some scetched code that wouldn't build / run.
This would involve three source code repos and a protocol field addition
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A runner would accept one job, run it, then exit.
This would allow for an external runner orchestrator to spin up completely fresh envs for each job (assuming running as non-docker/exec mode), in firecracker/fargate/tart/etc..
serverless runner?
Yeah, that could be one case. Where the orchestrator sees a job has come in and starts a new lambda run with a oneshot agent, and then when job is done agent will quit and lambda will stop.
Two act_runners can connect with the same token to Gitea Actions, while in GitHub Actions this is currently impossible due to session lock.
To reproduce execute
act_runner daemontwice with the same configuration.For example currently someone can craft a workflow file, which either
bind mount the runner config (container mode)This has been fixedYou are unaffected if the docker daemon and the act_runner has no shared folder containing .runner
Dind in the same container as act_runner is affected.
Finally use the token to receive jobs outside of your infrastructure. All jobs sent to the duplicated instance get access to new job requests and it's secrets.
Only allow to connect one runner with the same token at a time can increase security and make it harder to use the token while the job is running.
Finally ephemeral runners would fix the hole, if Gitea Actions would never send a second job to the runner.
This would be great to have. Along with ephemeral runners and a public API to generate short-lived, single-use runner registration tokens. It would allow us to create orchestration around spinning up/taring down runners.
For GitHub we wrote an auto-scaler that can spin up ephemeral self-hosted runner pools on potentially any IaaS, because we needed VMs/bare metal for runners (initially). I would love to try and add
giteaas a platform along side GitHub and GitHub enterprise server.closing as the linked PR has now been merged
I would request to reopen this issue, because I'm not aware of single use runner registrations access tokens.
e.g. once the server sent a job, block the runner from fetching another one.
In GitHub Actions Ephemeral != run once.
Would solve security implications of host mode.
That in no case someone can fetch another job regardless how much the runner is exploited.
Otherwise I create a new issue and may look into enhancing the server side
@ChristopherHX oh yes, thanks for that feedback. I will re-open :)
Created a technical proposal for server side here https://github.com/go-gitea/gitea/issues/32461 with some scetched code that wouldn't build / run.
This would involve three source code repos and a protocol field addition