XeplosionTechnologies/.forgejo

Watch

Fork

You've already forked .forgejo

Code Issues 19 Pull requests Projects 5 Releases Packages Wiki Activity Actions

Finalize host-side service and CI/CD isolation #37

New issue

Open

opened 2026-09-07 22:17:35 +00:00 by Xeplosion · 0 comments

Xeplosion commented

2026-09-07 22:17:35 +00:00

Owner

Copy link

Type of chore

Security hardening

What needs to be done and why?

Audit and finalize the current host-side isolation model for services and CI/CD runners managed by Xeplosion Technologies.

The previous infrastructure used broader shared deployment access that allowed automation associated with one service to reach resources belonging to other services. Much of the migration away from that model has already occurred, but the current hosts should be reviewed against the intended least-privilege architecture rather than continuing to follow assumptions from the old infrastructure plan.

The final state should ensure each service and runner has only the filesystem, process-management, and deployment access it actually requires.

Current-state inventory

Inventory all managed production/test hosts involved in CI/CD.
Inventory service accounts on each host.
Inventory Forgejo runner accounts.
Inventory legacy cicd, deploy, and shared service accounts.
Inventory service repository/data ownership.
Inventory current sudo rules.
Inventory SSH/forced-command access still in use.
Identify any account that can access unrelated service resources.

Service isolation

Confirm each independently managed service runs under an appropriate account.
Confirm service-owned files/directories have appropriate ownership.
Confirm private service data is inaccessible to unrelated service accounts.
Confirm service accounts use non-interactive shells unless interactive access is intentionally required.
Confirm service accounts do not have broad sudo access.
Restrict service-management sudo rules to the minimum required commands.
Document intentional exceptions.

Runner isolation

Confirm each Forgejo runner runs under the intended dedicated account.
Confirm runner workspaces have appropriate ownership and permissions.
Confirm runner accounts cannot access unrelated service-private data.
Confirm runner accounts have no unnecessary sudo permissions.
Confirm runner accounts have no unnecessary interactive SSH access.
Confirm runner labels route jobs to the correct hosts.

Legacy cleanup

Identify remaining dependencies on the retired shared-account model.
Migrate those dependencies.
Remove obsolete authorized keys.
Remove obsolete sudo rules.
Remove obsolete deployment directories.
Remove legacy users only after all dependencies have been verified gone.

Validation

Validate each affected service after permission changes.
Validate deployments after account/ownership changes.
Verify one service account cannot read another service's protected data.
Verify CI/CD cannot manage unrelated services without explicit permission.
Verify runner execution still succeeds.
Record any intentionally shared resources and why they must remain shared.

Documentation

Update infrastructure documentation to reflect the actual final account model.
Remove descriptions of obsolete deployment/security patterns.
Link substantial remaining migrations as separate issues.

Technical-debt impact

An incomplete migration leaves unclear trust boundaries, stale accounts, and multiple competing deployment/security models.

That makes future troubleshooting, access review, incident response, and automation changes more difficult.

Risk / compatibility impact

Account, ownership, sudo, and filesystem changes can interrupt running services or deployments.

Changes should be performed incrementally with validation after each affected service. Do not remove legacy access until the replacement path is confirmed working.

Affected branch(es)

The primary work is host configuration and is not inherently branch-specific.

Repository changes discovered during the audit should use their normal repository branch workflow.

Additional context

This issue owns host-side service and runner isolation.

Forgejo secret/token scoping is tracked separately so host permissions and repository credential policy can be reviewed independently.

Request checklist

I described why this work provides value or avoids future technical debt
I identified known risk, compatibility, or coordination concerns where applicable

Workflow lifecycle

Triage

Kind/ classification confirmed
Issue validity reviewed and appropriate Reviewed/ label assigned
Priority/ assigned when appropriate
Implementation branch referenced on the issue through Forgejo when applicable
Information requirements resolved; no Status/Needs More Info remains
Status/Needs Triage removed before leaving Triage

Backlog

Issue is confirmed valid and accepted into the project backlog

To Do

Scope and expected outcome are sufficiently defined
Known prerequisites, dependencies, and required decisions are resolved or understood
Work has been deliberately selected as upcoming work

In Progress

Assignee or active owner identified when appropriate
Forgejo timer started when time tracking provides meaningful value
Relevant implementation, research, or work notes recorded as needed
Forgejo timer stopped when active work ends, pauses, or becomes blocked

Review Gate

Review requirement assessed based on complexity, criticality, reversibility, and impact
If review is required: moved to In Review and appropriate testing / validation performed
If review is required: review comment records what was reviewed, how it was validated, findings, and outcome
If review is not required: rationale is evident from the low-risk nature of the change

Completed

Acceptance criteria / intended outcome satisfied
Related PRs, commits, documentation, or external changes linked where applicable
Resolution is documented by a linked PR that closes the issue, or by a final issue comment explaining what changed, how it was resolved, and how it was verified
Follow-up work split into separate issues where appropriate
Any Forgejo timer is stopped and recorded time is final
Issue moved to Completed and closed

### Type of chore Security hardening ### What needs to be done and why? ## What needs to be done and why? Audit and finalize the current host-side isolation model for services and CI/CD runners managed by Xeplosion Technologies. The previous infrastructure used broader shared deployment access that allowed automation associated with one service to reach resources belonging to other services. Much of the migration away from that model has already occurred, but the current hosts should be reviewed against the intended least-privilege architecture rather than continuing to follow assumptions from the old infrastructure plan. The final state should ensure each service and runner has only the filesystem, process-management, and deployment access it actually requires. ### Current-state inventory * [ ] Inventory all managed production/test hosts involved in CI/CD. * [ ] Inventory service accounts on each host. * [ ] Inventory Forgejo runner accounts. * [ ] Inventory legacy `cicd`, deploy, and shared service accounts. * [ ] Inventory service repository/data ownership. * [ ] Inventory current sudo rules. * [ ] Inventory SSH/forced-command access still in use. * [ ] Identify any account that can access unrelated service resources. ### Service isolation * [ ] Confirm each independently managed service runs under an appropriate account. * [ ] Confirm service-owned files/directories have appropriate ownership. * [ ] Confirm private service data is inaccessible to unrelated service accounts. * [ ] Confirm service accounts use non-interactive shells unless interactive access is intentionally required. * [ ] Confirm service accounts do not have broad sudo access. * [ ] Restrict service-management sudo rules to the minimum required commands. * [ ] Document intentional exceptions. ### Runner isolation * [ ] Confirm each Forgejo runner runs under the intended dedicated account. * [ ] Confirm runner workspaces have appropriate ownership and permissions. * [ ] Confirm runner accounts cannot access unrelated service-private data. * [ ] Confirm runner accounts have no unnecessary sudo permissions. * [ ] Confirm runner accounts have no unnecessary interactive SSH access. * [ ] Confirm runner labels route jobs to the correct hosts. ### Legacy cleanup * [ ] Identify remaining dependencies on the retired shared-account model. * [ ] Migrate those dependencies. * [ ] Remove obsolete authorized keys. * [ ] Remove obsolete sudo rules. * [ ] Remove obsolete deployment directories. * [ ] Remove legacy users only after all dependencies have been verified gone. ### Validation * [ ] Validate each affected service after permission changes. * [ ] Validate deployments after account/ownership changes. * [ ] Verify one service account cannot read another service's protected data. * [ ] Verify CI/CD cannot manage unrelated services without explicit permission. * [ ] Verify runner execution still succeeds. * [ ] Record any intentionally shared resources and why they must remain shared. ### Documentation * [ ] Update infrastructure documentation to reflect the actual final account model. * [ ] Remove descriptions of obsolete deployment/security patterns. * [ ] Link substantial remaining migrations as separate issues. ### Technical-debt impact An incomplete migration leaves unclear trust boundaries, stale accounts, and multiple competing deployment/security models. That makes future troubleshooting, access review, incident response, and automation changes more difficult. ### Risk / compatibility impact Account, ownership, sudo, and filesystem changes can interrupt running services or deployments. Changes should be performed incrementally with validation after each affected service. Do not remove legacy access until the replacement path is confirmed working. ### Affected branch(es) The primary work is host configuration and is not inherently branch-specific. Repository changes discovered during the audit should use their normal repository branch workflow. ### Additional context This issue owns **host-side service and runner isolation**. Forgejo secret/token scoping is tracked separately so host permissions and repository credential policy can be reviewed independently. ### Request checklist - [x] I described why this work provides value or avoids future technical debt - [x] I identified known risk, compatibility, or coordination concerns where applicable ### Workflow lifecycle ### Triage - [x] `Kind/` classification confirmed - [x] Issue validity reviewed and appropriate `Reviewed/` label assigned - [x] `Priority/` assigned when appropriate - [x] Implementation branch referenced on the issue through Forgejo when applicable - [x] Information requirements resolved; no `Status/Needs More Info` remains - [x] `Status/Needs Triage` removed before leaving Triage ### Backlog - [x] Issue is confirmed valid and accepted into the project backlog ### To Do - [ ] Scope and expected outcome are sufficiently defined - [ ] Known prerequisites, dependencies, and required decisions are resolved or understood - [ ] Work has been deliberately selected as upcoming work ### In Progress - [ ] Assignee or active owner identified when appropriate - [ ] Forgejo timer started when time tracking provides meaningful value - [ ] Relevant implementation, research, or work notes recorded as needed - [ ] Forgejo timer stopped when active work ends, pauses, or becomes blocked ### Review Gate - [ ] Review requirement assessed based on complexity, criticality, reversibility, and impact - [ ] If review is required: moved to **In Review** and appropriate testing / validation performed - [ ] If review is required: review comment records what was reviewed, how it was validated, findings, and outcome - [ ] If review is not required: rationale is evident from the low-risk nature of the change ### Completed - [ ] Acceptance criteria / intended outcome satisfied - [ ] Related PRs, commits, documentation, or external changes linked where applicable - [ ] Resolution is documented by a linked PR that closes the issue, or by a final issue comment explaining what changed, how it was resolved, and how it was verified - [ ] Follow-up work split into separate issues where appropriate - [ ] Any Forgejo timer is stopped and recorded time is final - [ ] Issue moved to **Completed** and closed

Xeplosion added the

Rows
Columns