Repository service account for Gitea Actions #11547

New Issue

GiteaMirror · 2025-11-02T09:40:45-06:00

GiteaMirror commented

2025-11-02 09:40:45 -06:00

Originally created by @merlleu on GitHub (Aug 27, 2023).

Feature Description

The issue:
Currently to allow the build of select repositories using actions, we create a token giving read-only to all repos and set it as action secret.
This is not ideal because in case of an infected repository: if a compromised (developer got gitea account hacked), the attacker could easily use actions to escalate privileges and access all the repos accessible by the access token.

One possible solution: Repository service accounts.
I was thinking a way of managing this would be to have the ability to create a service account linked to a specific repo:
The repository's actions jobs would inherit from a token with the service account permissions.

There would be an option to create the service account of a repo, adding a new tab to the settings page of the repo, listing permissions of the service account.

Permissions of the service account itself should be managed the same way as real accounts.
Service accounts should be have for username gitea_svc_{repo_id} and for full name {owner_name}/{repo_name}, and updating repo/owner name should update the service account full name.
Best thing would be to have a badge next to the name indicating it's a repo/service account.
They should be "login disabled".

I don't know if this feature might interest people out here but I think it might greatly reduces risks for CI/CD in my organization.

Screenshots

No response

Originally created by @merlleu on GitHub (Aug 27, 2023). ### Feature Description The issue: Currently to allow the build of select repositories using actions, we create a token giving read-only to all repos and set it as action secret. This is not ideal because in case of an infected repository: if a compromised (developer got gitea account hacked), the attacker could easily use actions to escalate privileges and access all the repos accessible by the access token. One possible solution: Repository service accounts. I was thinking a way of managing this would be to have the ability to create a service account linked to a specific repo: The repository's actions jobs would inherit from a token with the service account permissions. There would be an option to create the service account of a repo, adding a new tab to the settings page of the repo, listing permissions of the service account. Permissions of the service account itself should be managed the same way as real accounts. Service accounts should be have for username gitea_svc_{repo_id} and for full name {owner_name}/{repo_name}, and updating repo/owner name should update the service account full name. Best thing would be to have a badge next to the name indicating it's a repo/service account. They should be "login disabled". I don't know if this feature might interest people out here but I think it might greatly reduces risks for CI/CD in my organization. ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 09:40:45 -06:00

GiteaMirror commented

2025-11-02 09:40:46 -06:00

@Crown0815 commented on GitHub (Dec 14, 2023):

I think #25900 would resolve this issue very well. It would avoid the overhead of creating full blown service accounts and rather provide a very slim access layer.

@Crown0815 commented on GitHub (Dec 14, 2023): I think #25900 would resolve this issue very well. It would avoid the overhead of creating full blown service accounts and rather provide a very slim access layer.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11547