Skip to content

Policies discovery

Problem Statement

Organizations typically rely on GitLab's roles and permissions controls to maintain acceptable controls. However, GitLab's role system is typically considered too broad; for many customers - especially those operating in regulated environments - "they often resort to setting everyone to Master and trusting their colleagues to not make mistakes" (see research). In almost all cases, instances want to further constrain existing roles, instead of permit their users to do more.

In order for large organizations, especially regulated and security-minded enterprises, to thrive in GitLab we need more granular per-user permissioning.

Current status

We're currently trying to better understand the problem space before converging on a solution and are exploring and testing early stage wireframes.

  • If you're interested in the solution to this problem, please share more details on your needs as a comment.
    • How are you working around this problem now?
    • What specific controls would you like introduced?
    • Do you have any comments on the solutions we're exploring?

We conducted an Opportunity Canvas review on October 10th, which was approved. You can see the canvas here (public URL, anyone can comment):

Possible approach

Please see #7626 (closed) for the latest on the MVC.

Reach

This is primarily a problem for sysadmins (Sidney), team leads (Delaney) and Compliance/Security departments.

In terms of reach, I believe (based on the 48% of users encountering limitations) that the current role system in GitLab is sufficient for most but there's significant reach for improvements.

  • 3.0 = Significant reach (~25% to ~50%).

Impact

Among enterprises, especially those operating in regulated spaces, this can be a hard requirement for use of GitLab. Some existing enterprises have built complex workarounds/automation to manage around this problem, and it's one of Customer Success' most requested features.

  • 3.0 = Massive impact

Confidence

TODO: Add supporting information (issues, TAM toplist, etc).

  • 100% = High confidence

Effort

Based on nothing terribly substantive, I estimate:

  • Design/Research effort: High. We'll need to do a lot of discovery to make sure we get the new system right, since it will be hard to revert.
  • Product effort: Medium.
  • Engineering effort: Medium/High. Roles/permissions are a very mature part of the GitLab application and hard to make substantive changes to. If the solution we pursue involves ripping out the existing system, it will be incredibly expensive.

For the sake of t-shirt sizing, I'll estimate 3 person-months to get to the MVC.

Score

(3.0 Reach * 3.0 Impact * 100%) / 3.0 Effort = 3.0

Note: Maybe Impact scale should be the same as Reach 🤔

Links / references (GitLab internal)

Edited by Jeremy Watson (ex-GitLab)