Proposal: Custom Project Roles#276
Proposal: Custom Project Roles#276maxgraustenzel-create wants to merge 2 commits intogoharbor:mainfrom
Conversation
Signed-off-by: Max <max.grau.stenzel@gmail.com>
correction Signed-off-by: Max <max.grau.stenzel@gmail.com>
| **Timeline:** Completed | ||
|
|
||
| ### Phase 4: Security Validation (🔄 In Progress - 30%) | ||
| - Privilege escalation prevention (robot creation) |
There was a problem hiding this comment.
Could you clarify the subset check rule?
There was a problem hiding this comment.
The main idea is that when a user creates a robot accout it shall not use this to gain new permissions.
An example :
- a custom role based on the project maintainer with the additional permission to create robots (e.g. to implement project automation).
- a user with this role could define a robot that has more permissions than he has (e.g. like to change the configuration of the registry.)
In the current version privilege escalation scenario is not possible as only the administrator role that has all privileges is allowed to create robots.
The rule against escalation is : when creating a robot only the permissions of the role used to create the robot can be assigned to the robot. On the frondend the GUI guides the user, on the backend a check agains privilege escalation is implemented.
|
|
||
| ### Phase 4: Security Validation (🔄 In Progress - 30%) | ||
| - Privilege escalation prevention (robot creation) | ||
| - Privilege escalation prevention (member assignment) |
There was a problem hiding this comment.
When a role can assigne new members to the repository it shall not use this to assign members with more privileges (like administrator access).
| - **Minimal schema changes:** Only extend `role` table with metadata columns (`is_builtin`, `description`, `modified`, `created_by`, `modified_by`, timestamps) | ||
| - **Discriminator pattern:** `role_permission.role_type` distinguishes 'project-role' (users/groups) from 'robotaccount' (direct permissions) | ||
| - **System admin only:** Only system administrators can create/modify custom roles (project admins assign roles, existing workflow unchanged) | ||
| - **Built-in role protection:** Built-in roles can be modified but not deleted; modifications are tracked and reversible |
There was a problem hiding this comment.
Previously the built-in roles were fixed in the codebase. Does this mean that admins can now update the permissions of built-in roles via API or UI?
| │ │ policy (table) │ │ | ||
| │ └─────────────────┘ │ | ||
| │ │ | ||
| └──────────────────────────────────────────────────────────────┘ |
There was a problem hiding this comment.
Please give a table to define and describe the updated or new table schema.
|
|
||
| 1. **Database:** Move role permissions from hardcoded `rbac_role.go` to database (`role_permission` table) | ||
| 2. **API:** Add role CRUD endpoints for system administrators | ||
| 3. **UI:** Add role management interface in System Administration section |
There was a problem hiding this comment.
Could you give a sample screenshot of the UI change?
6 participants
Summary
Proposal to add custom project roles to Harbor, enabling system administrators to create roles with flexible permission combinations.
Related Issues
Implementation
origin/18124-custom-role-featureDiscussion
This proposal is ready for community review and discussion at the next community meeting.
Community Meeting
If wished, I could present this proposal and a demonstration of the role functionality at the next community meeting for feedback and discussion.
/kind proposal