"oneshot"/ephemeral runners #19

New Issue

techknowlogick · 2023-02-05T06:32:59Z

techknowlogick commented

2023-02-05 06:32:59 +00:00

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..

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..

👍 3

lunny commented

2023-02-05 06:53:43 +00:00

serverless runner?

techknowlogick commented

2023-02-05 07:31:04 +00:00

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.

> 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.

techknowlogick added the

kind

feature

label 2023-03-01 05:14:42 +00:00

ChristopherHX commented

2023-04-24 14:14:43 +00:00

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.

👍 1

ChristopherHX referenced this issue

2023-04-30 23:07:12 +00:00

Gitea act_runner is HIGHLY insecure due to binding of docker.sock into all containers (= root on host) #167

vicamo referenced this issue

2023-05-01 10:17:35 +00:00

Gitea act_runner is HIGHLY insecure due to binding of docker.sock into all containers (= root on host) #167

Matt0009 referenced this issue

2023-07-31 16:02:05 +00:00

gitea.run_id incorrect value #314

gabriel-samfira commented

2023-08-02 07:59:47 +00:00

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.

techknowlogick referenced this issue

2024-02-03 23:22:56 +00:00

act_runner with pve (Proxmox Virtual Environment) #472

Sign in to join this conversation.

No Milestone

No Assignees

4 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/act_runner#19