Forgejo/Gitea Actions #206

Open
opened 2024-03-08 14:44:56 +00:00 by benjaoming · 8 comments
Owner

Since Gitea 1.19, Gitea introcuded Gitea Actions. It's the same concept as GitHub Actions.

They're the called Forgejo Actions in Forgejo. You can see Forgejo Actions in action here:

https://codeberg.org/forgejo/forgejo/actions/runs/7849/jobs/1

Release notes from March 2023: https://blog.gitea.com/release-of-1.19.0/

Since Gitea 1.19, Gitea introcuded Gitea Actions. It's the same concept as GitHub Actions. They're the called Forgejo Actions in Forgejo. You can see Forgejo Actions in action here: https://codeberg.org/forgejo/forgejo/actions/runs/7849/jobs/1 Release notes from March 2023: https://blog.gitea.com/release-of-1.19.0/
benjaoming added the
Service Idea
Existing Service
Service Removal
Upgrade service
labels 2024-03-08 14:44:56 +00:00
Owner

Yeah, we actually "just" need to register some runners.

Yeah, we actually "just" need to register some runners.
Owner
https://forgejo.org/docs/next/admin/actions/#forgejo-runner
Owner

Seconded! In that case, and since we're gonna be using VMs, why not set up a dedicated runner VM with rootless Docker? That way, we can avoid it having access to our production Docker socket.

https://gitea.com/gitea/act_runner/src/branch/main/examples/vm/rootless-docker.md

Seconded! In that case, and since we're gonna be using VMs, why not set up a dedicated runner VM with rootless Docker? That way, we can avoid it having access to our production Docker socket. https://gitea.com/gitea/act_runner/src/branch/main/examples/vm/rootless-docker.md
samsapti added this to the Devops work project 2024-03-08 20:26:40 +00:00
Owner

yea it's been a bit iffy our current setup. especially considering the cryptojacker some years ago :(

yea it's been a bit iffy our current setup. especially considering the cryptojacker some years ago :(
Owner

Seconded! In that case, and since we're gonna be using VMs, why not set up a dedicated runner VM with rootless Docker? That way, we can avoid it having access to our production Docker socket.

https://gitea.com/gitea/act_runner/src/branch/main/examples/vm/rootless-docker.md

How is this different from the Forgejo docs (https://forgejo.org/docs/next/admin/actions/#forgejo-runner)? Emphasis is mine:

Installation of the OCI image

The OCI images are built from the Dockerfile which is found in the source directory. It contains the forgejo-runner binary.

$ docker run --rm code.forgejo.org/forgejo/runner:3.0.0 forgejo-runner --version
forgejo-runner version v3.0.0

It does not run as root:

$ docker run --rm code.forgejo.org/forgejo/runner:3.0.0 id
uid=1000 gid=1000 groups=1000

A docker-compose example is provided to demonstrate how to install that OCI image to successfully run a workflow.

> Seconded! In that case, and since we're gonna be using VMs, why not set up a dedicated runner VM with rootless Docker? That way, we can avoid it having access to our production Docker socket. > > https://gitea.com/gitea/act_runner/src/branch/main/examples/vm/rootless-docker.md How is this different from the Forgejo docs (https://forgejo.org/docs/next/admin/actions/#forgejo-runner)? Emphasis is mine: > Installation of the OCI image > > The OCI images are built from the Dockerfile which is found in the source directory. It contains the forgejo-runner binary. > > $ docker run --rm code.forgejo.org/forgejo/runner:3.0.0 forgejo-runner --version > forgejo-runner version v3.0.0 > > **It does not run as root:** > > $ docker run --rm code.forgejo.org/forgejo/runner:3.0.0 id > uid=1000 gid=1000 groups=1000 > > A docker-compose example is provided to demonstrate how to install that OCI image to successfully run a workflow.
Owner

The process inside the container does not run as root, but it still has access to the Docker socket (on our production VM!), unless we opt to use Docker-in-Docker which is also insecure due to the Docker-in-Docker container being privileged. In that case, the runner has access to the Docker socket of a priviliged container, which effectively grants it root access to that container, which in turn gives root access to the host due to said container being privileged. I don't really like that to be honest. That's why I suggest a dedicated runner VM where we run the Docker daemon itself as an unprivileged user (rootless Docker).

The process inside the container does not run as root, but it still has access to the Docker socket (on our production VM!), unless we opt to use Docker-in-Docker which is also insecure due to the Docker-in-Docker container being privileged. In that case, the runner has access to the Docker socket of a priviliged container, which effectively grants it root access to that container, which in turn gives root access to the host due to said container being privileged. I don't really like that to be honest. That's why I suggest a dedicated runner VM where we run the Docker daemon itself as an unprivileged user (rootless Docker).
Owner

Fair enough - but we're not talking about running act_runner are we?

Fair enough - but we're not talking about running act_runner are we?
Owner

No, we're gonna run the official Forgejo runner, but that uses a soft fork of act_runner.

Btw, I'm working on the rootless Docker setup over in proxmox.

No, we're gonna run the official Forgejo runner, but that uses a soft fork of act_runner. Btw, I'm working on the rootless Docker setup over in [proxmox](https://git.data.coop/data.coop/ansible/src/branch/proxmox).
Sign in to join this conversation.
No description provided.