dejima/dejima-ci-hardener
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Say that registration scope is the boundary, not the label

Browse Source 
A dedicated label routes honest jobs and stops nothing else: runs-on is in the
workflow file, the workflow file is in the branch, and a branch can name any
label. A session that redirects its jobs to a general-purpose runner has left
everything this tool installs behind, without touching any of it.

Gitea has no per-repository runner ACL - its FAQ points at registration scope
instead, and an instance-level runner serves every repository on the instance.
So a repository's CI posture is that of the weakest runner it can reach rather
than the one its workflow names, and hardening one runner on an instance that
also offers general-purpose ones buys less than it appears to.
This commit is contained in:
branderson
2026-08-05 17:30:16 -07:00
parent 2c9ace6842
commit d080098cd1
1 changed files with 35 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+35 -2
View File
@@ -83,8 +83,41 @@ they need:
| `examples/docker-daemon.json` | `/etc/docker/daemon.json` - merge, do not overwrite |
Set `--dns=<your gateway>` in the ordinary runner's `container.options`, and
register at **repository** scope so an unrelated repository cannot schedule
work onto a runner you hardened for this one.
register at **repository or organization** scope. That last part is not
housekeeping — see below.
### Register scope is the boundary; the label is not
A dedicated label routes honest jobs to the runner you prepared. It stops
nothing else, because `runs-on:` lives in the workflow file and the workflow
file lives in the branch. A branch can name any label it likes, so a session
that changes `runs-on: dejima-ci` to `runs-on: ubuntu-latest` and opens a pull
request has stepped outside everything this tool installs — provided some
runner answering that label will take the job.
Whether one will depends on where your runners are registered:
| Registered at | Which repositories it serves |
| --- | --- |
| Instance | **every repository on the instance** |
| Organization | that organization's repositories |
| Repository | that repository |
Gitea has no per-repository runner ACL; its FAQ points at registration scope
as the control instead, and gitea.com registers its own runners for a single
organization so they will not run other repositories' jobs.
**A repository's CI posture is that of the weakest runner it can reach, not
the one its workflow names.** So if the instance hosting these repositories
also offers general-purpose instance-level runners, hardening this one buys
less than it appears to. In rough order of preference:
1. Do not register general-purpose runners at instance level on an instance
that hosts repositories receiving agent-authored branches.
2. Harden every runner that repository can reach, so landing elsewhere changes
nothing that matters.
3. Move the repository to an instance or organization whose reachable runners
are all hardened.
## Verify