### Problem to solve Organizations often have support teams who need Admin read access to perform their job but should not have admin write access. This often leads to a bottleneck in work and slows work velocity down leading to inefficiencies. It also can impact compliance as orgs need to run a break glass procedure to grant the user access. ### Proposal Expand custom roles to support a "Custom Admin Role". Permissions include both read and write and will only be applicable to Admin Area as opposed to group and projects. ### Use cases for access * View runners and jobs to troubleshoot. * View subscription/billing to see count of users. * View list of users and user details to understand access challenges. * View monitoring details such as background migrations. * View application settings to troubleshoot. * Change specific application or instance settings ### Security model GitLab has 3 access types that can be assigned a user on self-managed: regular user, auditor, and administrator. A regular user or auditor user can be assigned a custom admin role for the Admin Area. <table> <tr> <th>Access</th> <th>Regular User</th> <th>Auditor</th> <th>Administrator</th> </tr> <tr> <td>Groups and projects</td> <td>Access by member role</td> <td> Read all groups and projects Write permissions by member role </td> <td>Full access</td> </tr> <tr> <td>Admin area</td> <td> Default: No access **Custom admin role:** Can read metadata based on X permission. Access to groups and projects from Admin Area based on member role.\* </td> <td> Default: No access **Custom admin role:** Can read metadata based on X permission. Access to groups and projects from Admin Area based on Auditor access.\*\* </td> <td>Full access</td> </tr> </table> \* A regular user assigned a custom admin role with `read_admin_cd` can see all runners and job metadata in the Admin Area. They can only click into the metadata of groups and projects if they have access to those groups/projects. \*\* An auditor user assigned a custom admin role with X permissions can see all metadata of all groups and projects related to X permissions in the Admin Area. They can also access contents of groups and projects based on the auditor permissions. ### Iterations * [Experimental - Custom Admin Role](https://gitlab.com/groups/gitlab-org/-/epics/15854) (Complete) * [Beta - Custom Admin Role](https://gitlab.com/groups/gitlab-org/-/epics/15956) (Complete) * [GA - Custom Admin Role](https://gitlab.com/groups/gitlab-org/-/epics/15957) (Complete in 18.3) ### Design https://gitlab.com/gitlab-org/gitlab/-/issues/502203+ ### Intended users * [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) * [Priyanka, (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager) ### What is the type of buyer? ~"GitLab Ultimate" ### Dogfooding Opportunity The [support team leverages admin access](https://handbook.gitlab.com/handbook/support/) for GitLab.com. These permissions may reduce the number of support members who need these elevated privileges. ### Reviewed by: * [x] Security * [x] Fulfillment (Billing) ### Success Metrics * Reduce the number of full-privileged admins on Ultimate namespaces by 25% MoM