This epic groups all epics that are required to move the `Permissions` category from `viable` to `competitive`. ## Problems to solve - “Developers are too limited in access”. - “Maintainers are too powerful”. “I don’t want a role that can be disruptive to the business such as deleting a resource.” - Default roles are too restrictive. I want to customize them and choose exactly what each role means. - Separation of duties is difficult to achieve given the current default role permissions which causes conflicts for compliance. - GitLab permissions table has become unwieldy and difficult to scale - both internally and externally for customers to understand. - The custom roles that inherit the default roles often need to have permissions subtracted. ## Requirements Themes are broken down by Permissions for Custom Roles, Management of Custom Roles, Access Insights, and Consolidated Policies. [Permissions for Custom Roles](https://gitlab.com/groups/gitlab-org/-/epics/12614 "Permissions for Custom Roles by Category") * Allow organizations to reduce Owners and Maintainers by creating a custom role with a lower default role + permission_x. This includes building out an inventory of permissions at these two levels. https://gitlab.com/groups/gitlab-org/-/epics/14086 * Create grouping of permissions that follow the CRUD model. These groupings may include repository, project planning, registries, and more. [Pending Research](https://gitlab.com/gitlab-org/ux-research/-/issues/2844 "Permission Management Mental Models (Validating CRUD use cases)"). https://gitlab.com/groups/gitlab-org/-/epics/12614 [Management of Custom Roles](https://gitlab.com/groups/gitlab-org/-/epics/13472 "Management of Custom Roles") * Allow an "empty" base-level that have no permissions attached so the user can start from scratch. Permissions can be appended on an empty role based on the users needs rather than constricting them to the default roles. [&12478](https://gitlab.com/groups/gitlab-org/-/epics/12478 "Ability to create a custom role without inheriting default roles") * Ability to use LDAP group link with custom roles. https://gitlab.com/groups/gitlab-org/-/epics/11915 * Robust permission selection UI. https://gitlab.com/groups/gitlab-org/-/epics/13515 * Ability to assign custom roles to groups. https://gitlab.com/gitlab-org/gitlab/-/issues/443369 * Attach a custom role to a token to inherit scope of permissions. https://gitlab.com/gitlab-org/gitlab/-/issues/434354 * Create a custom role based on a default role template, and allow the user to select/deselect permissions. https://gitlab.com/groups/gitlab-org/-/epics/12717 [Access Insights](https://gitlab.com/groups/gitlab-org/-/epics/12718 "Access Insights") * Any user can view the custom role permissions to identify what they have access to in a group or project. https://gitlab.com/groups/gitlab-org/-/epics/13061 * Export user permissions * View a list of roles and assigned users. https://gitlab.com/groups/gitlab-org/-/epics/13434 * Show inherited permissions of custom roles (pending testing) https://gitlab.com/groups/gitlab-org/-/epics/13061 * Ability to view what resources a user has access to. * Identify unused access on resources by user [Consolidated and Refactored Policies](https://gitlab.com/groups/gitlab-org/-/epics/13293 "Standardized and Consolidate Policies") 1. ... Default Role Enhancements 1. Continue to support the [5 default roles](https://docs.gitlab.com/ee/user/permissions.html#roles) today with a focus on security and usability. Exit Steps 1. To meet GitLab’s threshold for `Competitive`, GitLab must be dogfooding and able to show "significant use" of the features by GitLab the company. Use cases include: * TBD 2. Once the above are addressed, to mature the feature to `Competitive`, we must complete a Category Maturity scorecard with at least a 3.63 rating for the JTBD. See [Maturity documentation](https://about.gitlab.com/direction/maturity/). ## JTBD When enforcing my organization's access control policies in third-party software, I want to limit user access privileges to sensitive information and action, so I can ensure ensure only the people who require access have it and people who should not have access do not. ## Supporting Evidence - [Customer Feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/391760 "Customer Feedback - Granular Permissions") - [Custom Roles Epic](https://gitlab.com/groups/gitlab-org/-/epics/4035 "Custom Roles and Permissions") - [User Access Survey (internal)](https://docs.google.com/presentation/d/1K6Y648tOd_t-\_MX7o5XDYCB4zO6Cj1STnRYBP51HxZQ/edit#slide=id.g28dc9b4bac5_0_475) _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._ <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->