Issue CI/CD .forgejo security

Xeplosion commented

2026-06-15 16:43:00 -06:00

Owner

Type of chore

Security hardening

What needs doing and why?

The current CI/CD setup uses a single shared cicd user with org-level SSH credentials
(SSH_PRIVATE_KEY, SSH_USER) inherited by all repos. This means any repo's workflow
has the same server access as every other repo — a compromised workflow or stolen secret
can reach all services.

The planned security model (documented in INFRASTRUCTURE-VPS.md and INFRASTRUCTURE-HUB.md
on the docs branch) calls for full per-repo isolation on the Forgejo side. The following
work is outstanding:

Deploy keys

Generate a unique ed25519 keypair for each service repo
Register the public key as a deploy key on each corresponding Forgejo repo (read-only for git access)
Store the private key as SSH_PRIVATE_KEY in each repo's secrets (not org-level)
Remove SSH_PRIVATE_KEY and SSH_USER from org-level secrets once all repos are migrated
Per-repo secrets
Set SSH_USER per repo to the correct service user (e.g. svc-nginx, svc-mc-survival)
Set RELEASE_TOKEN per repo using a Forgejo application token scoped to that repo only
Confirm DEPLOY_TARGET is set per repo (vps or hub)
Demote SSH_PORT, VPS_HOST, HUB_HOST to org-level variables (non-secret)
CODEOWNERS
Confirm .forgejo/CODEOWNERS is present on main with .* @xeplosion
Add .forgejo/CODEOWNERS with .* @xeplosion to each template branch
Confirm branch protection on each template branch requires PR + xeplosion approval
Sync token
Confirm SYNC_TOKEN is scoped to .forgejo repo only, not org-level

Risk or impact

Until this is done, all service repos share the same server credentials. A malicious
or accidental change in any workflow can affect any service on either server. The org-level
SSH_PRIVATE_KEY is the primary risk — it should not exist at org level once per-repo
keys are in place.

No production behaviour changes. This is credential and permission restructuring only.

Additional context

Security model reference: docs branch → INFRASTRUCTURE-VPS.md, INFRASTRUCTURE-HUB.md

Deploy key generation per service:

ssh-keygen -t ed25519 -C "forgejo-<repo-name>" -f ~/.ssh/forgejo_<repo-name>

Checklist

I have described why this is worth doing now
I have noted any risk or impact on other work

### Type of chore Security hardening ### What needs doing and why? The current CI/CD setup uses a single shared `cicd` user with org-level SSH credentials (`SSH_PRIVATE_KEY`, `SSH_USER`) inherited by all repos. This means any repo's workflow has the same server access as every other repo — a compromised workflow or stolen secret can reach all services. The planned security model (documented in `INFRASTRUCTURE-VPS.md` and `INFRASTRUCTURE-HUB.md` on the `docs` branch) calls for full per-repo isolation on the Forgejo side. The following work is outstanding: **Deploy keys** - [x] Generate a unique ed25519 keypair for each service repo - [ ] Register the public key as a deploy key on each corresponding Forgejo repo (read-only for git access) - [ ] Store the private key as `SSH_PRIVATE_KEY` in each repo's secrets (not org-level) - [x] Remove `SSH_PRIVATE_KEY` and `SSH_USER` from org-level secrets once all repos are migrated **Per-repo secrets** - [ ] Set `SSH_USER` per repo to the correct service user (e.g. `svc-nginx`, `svc-mc-survival`) - [ ] Set `RELEASE_TOKEN` per repo using a Forgejo application token scoped to that repo only - [ ] Confirm `DEPLOY_TARGET` is set per repo (`vps` or `hub`) - [x] Demote `SSH_PORT`, `VPS_HOST`, `HUB_HOST` to org-level **variables** (non-secret) **CODEOWNERS** - [x] Confirm `.forgejo/CODEOWNERS` is present on `main` with `.* @xeplosion` - [x] Add `.forgejo/CODEOWNERS` with `.* @xeplosion` to each template branch - [x] Confirm branch protection on each template branch requires PR + xeplosion approval **Sync token** - [x] Confirm `SYNC_TOKEN` is scoped to `.forgejo` repo only, not org-level ### Risk or impact Until this is done, all service repos share the same server credentials. A malicious or accidental change in any workflow can affect any service on either server. The org-level `SSH_PRIVATE_KEY` is the primary risk — it should not exist at org level once per-repo keys are in place. No production behaviour changes. This is credential and permission restructuring only. ### Additional context Security model reference: `docs` branch → `INFRASTRUCTURE-VPS.md`, `INFRASTRUCTURE-HUB.md` Deploy key generation per service: ```bash ssh-keygen -t ed25519 -C "forgejo-<repo-name>" -f ~/.ssh/forgejo_<repo-name> ``` ### Checklist - [x] I have described why this is worth doing now - [x] I have noted any risk or impact on other work

Xeplosion added the

labels

2026-06-15 16:43:00 -06:00

Xeplosion self-assigned this

2026-06-15 16:43:51 -06:00

Xeplosion added this to the Infrastructure & Devops project

2026-06-15 16:43:56 -06:00

Xeplosion referenced this issue