Why You Should Contribute to Custom Roles

Background

GitLab has 6 out of the box roles that we are all familiar with (7 if you count auditor):

  • Minimal Access
  • Guest
  • Reporter
  • Developer
  • Maintainer
  • Owner

These static roles and their associated permissions are not flexible enough to account for our user's security and compliance needs. Most times, the role doesn't have enough permissions, and the customer is forced to raise the user to a more permissive level, which has too many, violating security best practices.

Our solution is to allow customers to define their own roles, loosely based off of the existing permissions table in our docs. Think of each checkmark as customizable: being able to be added to any less privileged role under it.

Why We Need Help

The ~"group::authentication and authorization" team has built the framework for customizable roles, but we need each individual feature team to get involved to split up (or consolidate) their permissions. As the SME's in their own area, they understand where the "boundaries" for each permission should be - which aspects make sense to be bundled together, where (both visually and in the API) the permission should stop and start - what the user has access to if they have that permission, what they don't have access to.

Why You Should Care

  • Hopefully this solves some long-standing blocked items in your backlog that were waiting for the magical day when customizable roles would arrive ✨
  • Contributing your permissions to the framework simplifies the currently complex permissions around your team's owned areas
  • When you go to add new features in the future, you can automatically make them consumable by customizable roles framework

How?

Engineering

Each group can follow the engineering contributor guidelines.

Product

We also need help from each individual group's product team to understand which permissions to prioritize. What are the top requests you've heard? Usually they come in some form like this:

  • I wish a [role] could do [action]
  • I wish a [role] didn't have the ability to [action]
  • I have to assign [role] because they have the ability to do this one [action] that I need, but I don't need any of the other things that come alone with [role]

For now, specific permission requests are being tracked in this issue.

Examples of Permissions Completed

These permissions were completed with the help of other teams:

  1. groupsource code : Split read code and download code MR
  2. View Vulnerability Report : Epic

Up Next

  1. ~"group::authentication and authorization" is working with groupthreat insights on Granular Security Permissions
  2. We can (and want to) work with more groups! Please just give @hsutor a heads up so we can devote some capacity for anything that comes up.
Edited by Hannah Sutor