Prevent jobs/artifacts from protected branches from being erased by developers
Problem to solve
Prevent jobs/artifacts from protected branches from being erased by developers.
Intended users
Further details
It is normal practice allow developers to push/merge to protected branches (master and release branches or tags) after passing code review and tests. Problem that with the current permission developers can erase jobs in pipelines they trigger, it is applicable even to protected branches. As result entire builds can be lost due to intentional or unintentional erasing.
By definition, protected branches/tags are supposed to be protected from ruining. Such branches can not be removed, history is not allowed to be rewritten in these branches. At the same time artifacts which are produced in pipelines for such branches can be easily removed by developers. In some cases rebuilding of previously built binaries can be complicated or impossible at all. This may put products under risk.
The current permissions scheme may confuse because more destructive action (job erasing) requires less permissions than less destructive option (artifacts erasing). Developers are not allowed to erase artifacts but they are allowed to erase jobs entirely (includes artifacts).
| Entry point | Action | Description |
|---|---|---|
POST /projects/:id/jobs/:job_id/erase |
Erases a job completely. Both artifacts and build logs/traces are completely erased. This is most destructive option. | At least Developer role is required. Developers can erase jobs they triggered using this API entry action. |
DELETE /projects/:id/jobs/:job_id/artifacts |
Erases only artifacts. Less destructive action. | At least Maintainer role is required for performing this operation. |
Proposal
Do not allow users with Developer role to erase any jobs in protected pipelines (pipelines which are triggered for protected branches).
Users with higher role will be still able to erase jobs.
Current permissions scheme
| Action | Guest, Reporter | Developer | Maintainer | Admin |
|---|---|---|---|---|
| See commits and jobs | ✓ | ✓ | ✓ | ✓ |
| Retry or cancel job | ✓ | ✓ | ✓ | |
| Erase job artifacts and trace | ✓ (1) | ✓ | ✓ | |
| Remove project | ✓ | ✓ | ||
| Create project | ✓ | ✓ | ||
| Change project configuration | ✓ | ✓ | ||
| Add specific runners | ✓ | ✓ | ||
| Add shared runners | ✓ | |||
| See events in the system | ✓ | |||
| Admin interface | ✓ |
- 1: Only if the job was triggered by the user
Proposed permissions scheme
| Action | Guest, Reporter | Developer | Maintainer | Admin |
|---|---|---|---|---|
| See commits and jobs | ✓ | ✓ | ✓ | ✓ |
| Retry or cancel job | ✓ | ✓ | ✓ | |
| Erase job artifacts and trace | ✓ (1) | ✓ | ✓ | |
| Remove project | ✓ | ✓ | ||
| Create project | ✓ | ✓ | ||
| Change project configuration | ✓ | ✓ | ||
| Add specific runners | ✓ | ✓ | ||
| Add shared runners | ✓ | |||
| See events in the system | ✓ | |||
| Admin interface | ✓ |
- 1: Only if the job was triggered by the user and only if the job is not within the pipeline which was created for a protected ref
Permissions and Security
GitLab CI/CD permissions have to be adjusted to satisfy this request.
Documentation
Permissions documentation have to be updated: https://docs.gitlab.com/ee/user/permissions.html.
Testing
No quality risks.
Already existing tests have to be extended.
What does success look like, and how can we measure that?
In case of success none of jobs/artifacts owned by protected pipelines will be allowed to be erased by users with Developer role. This is coverable by automatic tests.
What is the type of buyer?
- Core
Links / references
-