UX: Access & Permissions

Problem and scope

See details

What is the problem to solve?

Security policy management is currently tied to GitLab project permissions, forcing security teams to be added as project members to manage policies. This creates several problems:

  • Security teams need developer/maintainer access to projects they shouldn't have code access to
  • No way to delegate policy management without giving full project access
  • Permissions are scattered across projects rather than centrally managed
  • No dedicated security/compliance role that works across the organization

Focus: WHO can do what with policies

  • Permission model (who can create/edit/delete policies)
  • Role definitions (Policy Admin vs Policy Manager vs Viewer)
  • How permissions are assigned/inherited
  • Security team access across projects they don't own
  • Delegation of policy management
  • Audit trail of who did what

Example: "As a Security Admin, I should be able to create policies for any project in my organization, even if I'm not a project member"

Who is the design solution for?

  • Primary: Security Team Leads who need to delegate policy management
  • Secondary: Compliance Officers who need oversight without code access
  • Tertiary: Organization Admins managing security team permissions

What is the Job this user is trying to achieve?

  • Grant policy management permissions based on job role, not project membership
  • Delegate policy responsibilities without compromising security
  • Maintain clear separation of duties between code and policy access
  • Track who can manage policies and what changes they make
  • Scale security team operations across hundreds of projects

What outcomes is this design solution helping them achieve?

If you have measured Outcome data, put that in the table. If not, delete the table and add the Outcomes to be designed for in a bulleted list.

  • Minimize the time to grant appropriate policy permissions
  • Minimize security risks from overly broad project access
  • Minimize the effort to track policy management permissions
  • Minimize confusion about who can modify policies

What are the requirements necessary to solve for this problem and Outcomes?

{ Create a bulleted list of everything that will need to be addressed in the holistic Design Vision in order to fully solve for the problem and Outcomes. Work with your counterparts to define this list. Keep it solution agnostic and try to understand any technical constraints that each requirement may imply. Only remove a requirement due to a technical constraint if it's not technically feasible to build within a reasonable amount of time (1-3 milestones is reasonable, anything longer than that you'll have to decide as a team how important it is to keep it in scope or address it in parallel in later iterations). }

  • Define clear policy management roles (Admin, Manager, Viewer)
  • Assign roles at organization/group level
  • Role inheritance and override mechanisms
  • Scope-based permissions (manage policies for specific groups/projects)
  • Clear permission visualization
  • Audit trail of permission changes
  • Bulk permission management
  • Integration with existing GitLab roles where appropriate
  • Permission delegation workflows
  • Time-based permission grants
  • Permission approval workflows for sensitive changes

What supporting research or customer validation do we have?

  • { TBD }

What is the timeline?

  • { TBD }

What are the technical constraints?

{ ⚠️ This is to understand initial constraints in which the design solution needs to work within, NOT whether the solution can be implemented in a given milestone.

Once the Product Designer has come up with a holistic Design Vision, or an ideal state for solving the problem, they should collaborate with their team members and engineers to continue the technical feasibility discussion during workflowplanning breakdown. }

  • Must integrate with existing GitLab permission system
  • Cannot break existing project-based permissions during transition
  • Need to support custom roles framework
  • Must maintain compliance with SOC2/regulatory requirements
  • Performance impact of permission checks must be minimal

In what parts of GitLab will this solution be available?

 Plans:
  • Free
  • Premium
  • Ultimate

Instances:

  • Self-managed
  • Dedicated
  • GitLab.com

Levels:

  • Instance
  • Group
  • Project

How will we know if the solution is successful?

  • x% reduction in unnecessary project memberships for security teams
  • Reduction in permission assignment time
  • Clear audit trail for x% of policy changes
  • Reduction in compliance violations due to permission confusion
  • x% reduction in permission-related support tickets

Ready for design

See checklist
  • The problem has been defined and is well understood
  • Who the design solution is for has been defined
  • User goals and outcomes have been defined
  • Supporting research has been reviewed and linked
  • The product requirements have been defined, and the scope has been agreed upon
  • Success metrics have been defined and agreed upon
  • I, as the Product Designer, believe I have all the information I need to begin creating a design solution
  • Move this issue to ~"workflow::ready for design" or workflowdesign 🎉
  • (Optional) Help improve this issue template, view feedback issue

Proposal

See checklist reminder
  • 📺 Walkthrough
  • 🖼️ Design Solution Proposal
  • ❖ Figma project →

Design breakdown

Once the proposal is agreed upon, work with your team to break it down into buildable parts (MVC, Iteration 1, Iteration 2, etc... until fully built).

See checklist
  • Design Vision broken down into MVC and follow-up iterations based on their ability to stand alone and provide value to the user
  • Create MVC and other necessary Iteration 1, Iteration 2... issues and add them as Linked items to this issue
    • Include all necessary requirements, and specs needed to create the designs for each broken down issue
Edited by 🤖 GitLab Bot 🤖