XeplosionTechnologies/.forgejo

Watch

Fork

You've already forked .forgejo

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

Finalize Forgejo CI/CD credential isolation #38

New issue

Open

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

Xeplosion commented

2026-09-07 22:22:55 +00:00

Owner

Copy link

Type of chore

Security hardening

What needs to be done and why?

Audit and finalize the Forgejo-side credential model used by CI/CD.

Deployment and automation credentials should be scoped so that compromise or accidental misuse of one repository does not automatically grant equivalent access to unrelated repositories or services.

The previous security work already completed portions of the migration, including some organization-variable cleanup and template protections. This issue should verify the actual current configuration and finish the remaining credential isolation.

Current-state audit

Inventory organization-level secrets.
Inventory organization-level variables.
Inventory repository-level deployment secrets.
Inventory repository deploy keys.
Inventory release tokens.
Inventory synchronization/template-system tokens.
Identify credentials shared more broadly than required.
Identify stale or unused credentials.

Deployment credentials

Confirm deployable repositories use appropriately isolated credentials.
Confirm private deployment keys are repository-scoped where isolation is required.
Confirm deployment usernames match the intended service identity.
Confirm deployment target configuration is scoped correctly.
Confirm non-secret host/port configuration uses variables rather than secrets where appropriate.
Validate deployment after each credential migration.

Release credentials

Review current release-token usage.
Minimize token permissions where Forgejo allows.
Confirm repositories without release automation do not receive unnecessary release credentials.
Document token ownership and rotation expectations.

Template / synchronization credentials

Review synchronization-token scope.
Confirm synchronization credentials are only available to workflows that require them.
Confirm template automation does not receive unrelated deployment credentials.
Confirm canonical template branches remain protected from unauthorized changes.

Repository protections

Confirm CODEOWNERS coverage for canonical .forgejo assets.
Confirm branch protection on main.
Confirm protection on managed template branches.
Confirm high-impact workflow/template changes require appropriate review.
Confirm template repositories cannot become unintended competing sources of truth.

Cleanup

Remove superseded organization-level secrets.
Remove stale repository secrets.
Remove obsolete deploy keys.
Rotate credentials where continued reuse is not appropriate.
Verify no secrets are stored in documentation, issues, commits, or workflow output.

Validation

Confirm each affected deployment works with its final credential.
Confirm a repository cannot authenticate as an unrelated service.
Confirm synchronization still works.
Confirm release automation still works.
Confirm runner routing and workflow execution still work.

Documentation

Document the final organization-variable model.
Document which secrets are repository-scoped.
Document synchronization/release credential requirements.
Reference this model from CI/CD guidance.
Reference this model from the New Organization setup page.

Technical-debt impact

A mixed or unclear credential model makes the real trust boundary difficult to audit and increases the cost of future credential rotation or security review.

Risk / compatibility impact

Changing credential scope can immediately break deployments, releases, or synchronization.

Migrate incrementally and validate each consumer before removing superseded credentials.

Affected branch(es)

Canonical workflow/template changes, if required, should target main.

The credential configuration itself is primarily Forgejo repository/organization configuration rather than branch-specific work.

Additional context

The original security issue identified shared organization-level deployment credentials as the principal cross-repository risk; several protective steps have since been completed.

This issue owns Forgejo-side secrets, tokens, deploy keys, and repository protection, while server account/filesystem isolation is tracked separately.

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? Audit and finalize the Forgejo-side credential model used by CI/CD. Deployment and automation credentials should be scoped so that compromise or accidental misuse of one repository does not automatically grant equivalent access to unrelated repositories or services. The previous security work already completed portions of the migration, including some organization-variable cleanup and template protections. This issue should verify the actual current configuration and finish the remaining credential isolation. ### Current-state audit * [ ] Inventory organization-level secrets. * [ ] Inventory organization-level variables. * [ ] Inventory repository-level deployment secrets. * [ ] Inventory repository deploy keys. * [ ] Inventory release tokens. * [ ] Inventory synchronization/template-system tokens. * [ ] Identify credentials shared more broadly than required. * [ ] Identify stale or unused credentials. ### Deployment credentials * [ ] Confirm deployable repositories use appropriately isolated credentials. * [ ] Confirm private deployment keys are repository-scoped where isolation is required. * [ ] Confirm deployment usernames match the intended service identity. * [ ] Confirm deployment target configuration is scoped correctly. * [ ] Confirm non-secret host/port configuration uses variables rather than secrets where appropriate. * [ ] Validate deployment after each credential migration. ### Release credentials * [ ] Review current release-token usage. * [ ] Minimize token permissions where Forgejo allows. * [ ] Confirm repositories without release automation do not receive unnecessary release credentials. * [ ] Document token ownership and rotation expectations. ### Template / synchronization credentials * [ ] Review synchronization-token scope. * [ ] Confirm synchronization credentials are only available to workflows that require them. * [ ] Confirm template automation does not receive unrelated deployment credentials. * [ ] Confirm canonical template branches remain protected from unauthorized changes. ### Repository protections * [ ] Confirm CODEOWNERS coverage for canonical `.forgejo` assets. * [ ] Confirm branch protection on `main`. * [ ] Confirm protection on managed template branches. * [ ] Confirm high-impact workflow/template changes require appropriate review. * [ ] Confirm template repositories cannot become unintended competing sources of truth. ### Cleanup * [ ] Remove superseded organization-level secrets. * [ ] Remove stale repository secrets. * [ ] Remove obsolete deploy keys. * [ ] Rotate credentials where continued reuse is not appropriate. * [ ] Verify no secrets are stored in documentation, issues, commits, or workflow output. ### Validation * [ ] Confirm each affected deployment works with its final credential. * [ ] Confirm a repository cannot authenticate as an unrelated service. * [ ] Confirm synchronization still works. * [ ] Confirm release automation still works. * [ ] Confirm runner routing and workflow execution still work. ### Documentation * [ ] Document the final organization-variable model. * [ ] Document which secrets are repository-scoped. * [ ] Document synchronization/release credential requirements. * [ ] Reference this model from CI/CD guidance. * [ ] Reference this model from the New Organization setup page. ### Technical-debt impact A mixed or unclear credential model makes the real trust boundary difficult to audit and increases the cost of future credential rotation or security review. ### Risk / compatibility impact Changing credential scope can immediately break deployments, releases, or synchronization. Migrate incrementally and validate each consumer before removing superseded credentials. ### Affected branch(es) Canonical workflow/template changes, if required, should target `main`. The credential configuration itself is primarily Forgejo repository/organization configuration rather than branch-specific work. ### Additional context The original security issue identified shared organization-level deployment credentials as the principal cross-repository risk; several protective steps have since been completed. This issue owns **Forgejo-side secrets, tokens, deploy keys, and repository protection**, while server account/filesystem isolation is tracked separately. ### 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 - [x] 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