[go: up one dir, main page]
Skip to content

[PILOT] Discuss Design Pod for RBAC UX

Problem to solve

There are several teams that have a need to allow users to set up access "rules" that can be easily spread across multiple Groups or Projects. This is necessary when you have 100s or 1000s of Projects that need a rule or set of rules added to them. To do this on a case-by-case basis is time-prohibitive.

This problem is likely slowing down the adoption of GitLab in the enterprise space.

UX Problem(s)

How might we enable organizations to administer role-based access controls relevant to their operational structure and policy requirements as they relate to the use of GitLab?

UX Problem space

  • Information Architecture: Administering access controls in one location for the entire organization
  • Taxonomy: Defining the terminology central to this capability
  • Workflow: Defining the experience for administering access controls to users and groups of users

Proposal

Gather UX-oriented team from relevant Stage Groups that will come together to work collaboratively to solve the problem at hand. Teams will be comprised of Product Designers, Product Managers and Product Design Managers. Relevant engineering teams should be brought in on a case-by-case basis to help understand and solve any technical constraints or problems but they do not need to be full members of the Design Pod.

Design Pod team

Direct participants

Pending approval

Participant Roles Notes
@andyvolpe Responsible Understanding of RBAC and Policies will help guide conversations and maintain direction of the POD
@dmoraBerlin Accountable DRI of Manage:Access, will help ensure solutions are viable and conform to product vision
@ameliabauerly Accountable DRI of Incident Management, will help ensure current needs of users are met
@beckalippert Consulted DRI of Threat Insights, will help ensure current needs of users are met
@cam.x Consulted DRI of Security Orchestration, will help ensure current needs of users are met
@dfosco Consulted DRI of Release, will help ensure current needs of users are met
@aregnery Consulted DRI of Compliance Frameworks and Auditing will help fill out any gaps downstream of Access controls and ensure users needs are met
@npost Consulted DRI of workspaces, will help ensure solutions are architecturally viable and provide insight into their creation
@mnichols1 Consulted DRI of Source Code Rules
@v_mishra Consulted DRI of Pipeline permissions
@jmandell Informed Product Design Manager of Secure & Protect and Monitor UX teams

In addition, we'll ensure we loop in the following PMs for advice/review:

PM Role Notes
matt_wilson Consulted Secure - vulnerability management
abellucci Consulted Monitor - incident management
hsutor Consulted Access
gweaver Informed Plan - resource for merging of groups/projects
mushakov Informed Group Product Manager
kbychu Informed Group Product Manager

Role Definition

Using the RACI model we can begin assigning roles based on product area and capacity. This is still To Be Determined.

  • Responsible: a manager or team member who is directly responsible for successfully completing a project task.
  • Accountable: the person with final authority over the successful completion of the specific task or deliverable.
  • Consulted: someone with unique insights the team will consult.
  • Informed: a client or executive who isn’t directly involved, but you should keep up to speed.

What does success look like?

  1. Summary of the problem space
  2. What is our MVC for solving this?
    1. Are we going to allow roles to be defined "from scratch" or do we allow them to add/subtract from the roles that exist today? Is there ever a case for a role to be applied at the group level, or only a member?
  3. Package #1 and #2 and collaborate with Engineering so that they can do a spike/investigation into any technical limitations around the proposed MVC

Plan (TBD)

Activities:

Research:

🎥 Dovetail interviews

1. Understand the Problem space

In each product area, we need to perform Problem Validation with users around the topic of Access Controls in their 3rd Party Software.

  • Who are the personas doing these activities
  • What are their JTBD (motivations, jobs, desired outcomes)
2. Understand the solution space:

I wanted to capture these questions from this thread as the frame the solution space rather nicely. These should be used as guidence at this point, until problem validation is complete.

  • Where do I create and view roles?
    • Should this be at Workspace/Group level and cascade down? What about sub-groups?
    • Can I override or create a role at the Project level?
  • Where do I apply roles to users?
    • Does a role get applied directly to a user and then that user has the role's permissions for any group or project to which they are assigned? Or must a user be added to a group or project and assigned a role specific to that context to gain any access?
  • If I wanted to see a complete picture of all users assigned to a role, where/how would I do that?
  • If I wanted to see a complete picture of all roles and permissions assigned to a given user across all their groups and projects, where/how would I do that?

Design:

1. Pin down expected workflows

Daniel will lead this process and Andy/Amelia will provide review/comments.

2. Work on better grouping for current permissions table.

Andy and Amelia will work on re-grouping the existing content in #281169 (closed).

3. Wireframes

Rough wireframes will be created by the end of 14.8. Daniel will be lead designer, Andy and Amelia will review/comment.

Deliverables:

  1. Informed direction/solution on RBAC in GitLab
  2. Informed direction and strategy on the additional peripheral components required by RBAC. These include but are not limited to, CRUD action (Create, Read, Update, Destroy), JIT (Just-in-time access) and Auditing (how users generate an audit of their access controls, if necessary)

Timeline:

Working timeline for activities. This is a rough estimate and is still TBD.

  • FY22-Q3: Informed problem and data

  • FY22-Q4: Informed solution, direction and strategy.

  • FY23-Q1: Workflows and wireframes completed for MVC

Links / references

RBAC Information

Past work related to Access Controls

Policies at GitLab

Figma work file

Edited by Amelia Bauerly