Custom Roles Should Not Inherit Approval Capabilities from Base Roles in MR Policies
Current Behaviour: When a custom role is created based on a base role (e.g., Developer), users assigned to that custom role automatically inherit the approval capabilities of the base role. This means if an MR approval policy specifies role_approvers: [developer], users with a custom role based on Developer can approve the MR, even if the custom role was created solely to add specific additional permissions.
Example:
- A custom role "Senior Engineer" is created based on the Developer base role
- Additional permissions are added:
READ_COMPLIANCE_DASHBOARD,ADMIN_CICD_VARIABLES,MANAGE_PROJECT_ACCESS_TOKENS,ADMIN_VULNERABILITY,ADMIN_WEB_HOOK - An MR approval policy requires approval from users with the Developer role
- Users assigned the "Senior Engineer" custom role can approve the MR
- This violates SSDLC RBAC principles and segregation of duties
Security Impact: This behaviour creates unintended privilege escalation and breaks role-based access control (RBAC) segregation of duties, as custom roles inherit approval authority they were not explicitly designed to have.
Proposal
Desired Behavior: When an MR approval policy specifies a base role (e.g., Developer) as an approver, only users with that exact base role should be eligible to approve. Users assigned to custom roles based on that base role should NOT automatically inherit approval capabilities.
Implementation:
- Modify MR approval policy role matching logic to distinguish between base roles and custom roles
- When
role_approvers: [developer]is specified, only users with the Developer base role can approve - Users with custom roles based on Developer would need to be explicitly added as approvers if they should have approval authority
- This applies to all base roles (Developer, Maintainer, Owner, etc.) and their derived custom roles
Benefits:
- Enforces proper RBAC and segregation of duties
- Prevents unintended privilege escalation through custom role inheritance
- Gives administrators explicit control over who can approve MRs
- Aligns with security best practices for role-based access control