[go: up one dir, main page]

Permission alignment for OWNER and MAINTAINER role in groups and projects

Premise

see also: Permissions movement for parity (&8784)

Planning for %16.0 (when this will be a breaking change):

Premise:

Earlier, the role of OWNER was only available at the group level and not available at the project level. Anyone who was an OWNER at the group level naturally became an OWNER in projects within the group, but we did not support adding a member as OWNER directly to a project.

OWNERS were the highest possible access level in a group, and MAINTAINERS were supposed to be the highest possible access level in a Project. OWNERS from ancestral groups were of course treated as Owners at the Project level, and hence they had some "destructive" permissions in Projects that MAINTAINERS did not have. (For example, only OWNERS in a project can delete the project, MAINTAINERS can not. See the screenshot below for a full list of permissions.)

Screenshot_2022-09-20_at_12.55.54_PM

Recently, we have introduced changes to support directly adding members as OWNER in a project. Hence, the next action item we want to pursue is to bring parity between group OWNERS and project OWNERS, ie, we want their permissions of OWNERS in both entities to be more or less the same.

For instance, today, group OWNERS can add/delete/update members in a group. However, in a project, even MAINTAINERS can do the same function. This brings discrepancy in permissions, when you consider the overall picture. We want to avoid this discrepancy.

Now, there are 2 ways to accomplish this. ~"group::workspace" has decided to make use of both of them depending on the permission. Each comes with its own sets of pros and cons:

  • We will move some permissions from group OWNERS and give it to group MAINTAINERS. For instance, we will bring about a breaking change such that group MAINTAINERS can now add/delete/update members in groups, and this is in line with how project MAINTAINERS currently behave.
  • We will remove some permissions from project MAINTAINERS and give it to project OWNERS. For instance, we will bring about a breaking change such that only project OWNERS will be able to create deploy tokens for projects from now on, and this is in line with how group OWNERS currently behave.

Both these approaches are breaking changes, and will have consequences, but if we want to achieve parity in how OWNERS behave across these 2 entities, this is the only possible way.

And hence, we will make use of the following plan:

  • From %15.0 to %16.0 - within a project, both MAINTAINERS and OWNERS will have similar permissions. The only exception is - MAINTAINERS won't have any permissions regarding creating, deleting or updating other members to OWNER access, as this would a security issue.
  • Before %16.0, we announce to customers along the lines of From GitLab 16.0, the OWNER and MAINTAINER roles will be aligned between groups and projects. This means that MAINTAINERS in a project would no longer have the <following permissions> in a project, starting from 16.0 and they will only be available to OWNERS. At the same time, the <following permissions> will move from group OWNERS to group MAINTAINERS. We advise you to promote those MAINTAINERS who would continue to require access to any of the following permissions to OWNER before GitLab 16.0.

What are the permissions that are going to be affected?

We should make a list of this. As a general rule of thumb, we want to ensure that destructive actions (such as deleting a project/group) are controlled well by limiting it to the OWNER role. Constructive actions, such as maintaining membership, can be expanded to be performed by both OWNERS and MAINTAINERS in either groups or projects.

A non exhaustive list:

  • creation/modification/deletion of group access tokens should be allowed to group MAINTAINERS as well.
  • creation/modification/deletion of group members should be allowed to group MAINTAINERS as well.
  • permission to accept member access requests in groups should be allowed to group MAINTAINERS as well.
  • permission to register new runners should only be allowed to project MAINTAINERS.
  • permission to reset project runner registration token should only be allowed to project MAINTAINERS.
  • < Add more >

Why Should You Care?

This is an opportunity to create further distinctions between the OWNER and MAINTAINER role. At the same time, it is an opportunity to align permissions between groups and projects if you have features that apply to both of them. As part of a larger effort to consolidate groups and projects, we recommend to apply the same permissions for roles, regardless of whether the role is part of a group or project.

To Do

  • Please check for your team and features whether you have any rights associated with the OWNER or MAINTAINER role in a group or project.
    • How can you check? An engineer could look into the policy files.
    • If Yes for groups, add Y to the column Permissions available for group OWNER and MAINTAINER?
      • If No, add N to the column
    • If Yes for projects, add Y to the column Permissions available for project OWNER and MAINTAINER?
      • If No, add N to the column
  • If you have answered Yes for the previous two columns, please check whether the permissions are aligned between group and project owners
    • If Yes for groups, add Y to the column Are group and project MAINTAINER and OWNER permissions aligned?
      • If No, add N to the column
  • If you have answered No in the column Are group and project MAINTAINER and OWNER permissions aligned?, please indicate whether you are planning to align these permissions in %16.0 in the column Are you planning to align them in 16.0? (Y / N)

If nothing is done, permissions will remain available as they currently are for both the MAINTAINER and OWNER role. Aligning them should be a combined effort between all teams, otherwise customers would repeatedly face the decision to change permissions based on new changes with every major milestone. If we align them all together at the same time, we can give customers a comprehensive list of the expected changes to base their decision on. Since this is going to be a breaking change, we are planning to announce this well ahead of time to customers. If permissions other than the ones owned by ~"group::workspace" are affected, we should ensure to work on this communication together. This is an effort to avoid feedback like this.

Overview

Stage Group PM Permissions available for group OWNER and MAINTAINER? Permissions available for project OWNER and MAINTAINER? Are group and project MAINTAINER and OWNER permissions aligned? Are you planning to align them in 16.0?
Manage Authentication & Authorization @hsutor Y Y TBD
Manage Workspace @lohrc Y Y N Y
Manage Import @m_frankiewicz Y Y N
Manage Foundations @cdybenko N N n/a n/a
Manage Integrations @g.hickman N N n/a
Plan Optimize @hsnir1
Plan Project Management @gweaver N Y N
Plan Planning @amandarueda
Plan Certify @mmacfarlane Y Y Y
Create Source Code @tlinz
Create Code Review @phikai
Create Editor @ericschurter Y Y Y N/A
Verify Pipeline Execution @jreporter Y Y N N
Verify Pipeline Authoring @dhershkovitch Y Y N N
Verify Pipeline Insights @jocelynjane N Y Y N
Verify Runner @DarrenEastman Y Y N Y (#383683, #383685)
Package Package @trizzi Y Y N Yes
Release Release @cbalane
Configure Configure @nagyv-gitlab Y Y Y
Monitor Respond @abellucci Y Y Y n/a
Monitor Observability @sebastienpahl
Secure Static Analysis @connorgilbert
Secure Dynamic Analysis @derekferguson N N n/a n/a
Secure Composition Analysis @sam.white N N n/a n/a
Secure Vulnerability Research @hbenson
Govern Security Policies @sam.white Y Y Y n/a
Govern Threat Insights @matt_wilson Y Y Y n/a
Govern Compliance @derekferguson Y Y N
Anti-Abuse Anti-Abuse @jstava
ModelOps Applied Machine Learning @tmccaslin Y Y Y
ModelOps MLOps @tmccaslin Y Y Y
ModelOps DataOps @tmccaslin Y Y Y
Analytics Product Intelligence @stkerr
Analytics Product Analytics @jheimbuck_gl
Growth Acquisition @gdoud N N N n/a
Growth Activation @p_cordero N N N n/a
Fulfilment Purchase @alex_martin Y N N n/a
Fulfilment Provision @courtmeddaugh
Fulfilment Utilization @doniquesmit
Fulfilment Fulfilment Platform @mgass1 N Y N n/a
Fulfilment Billing & Subscription Management @tgolubeva Y N N n/a
Fulfilment Commerce Integrations @courtmeddaugh
Fulfilment Fulfilment Admin Tooling @doniquesmit
Systems Distribution Build @dorrino n/a n/a n/a n/a
Systems Distribution Deploy @dorrino n/a n/a n/a n/a
Systems Gitaly @mjwood N N n/a n/a
Systems Geo @sranasinghe N N n/a n/a
Data Stores Application Performance @rogerwoo N N n/a n/a
Data Stores Global Search @changzhengliu N N n/a n/a
Data Stores Database @rogerwoo rwoo N N n/a n/a
Data Stores Pods @fzimmer N N n/a n/a
SaaS Platforms Delivery @awthomas N N n/a n/a
SaaS Platforms Scalability @awthomas N N n/a n/a
SaaS Platforms GitLab Dedicated @awthomas N N n/a n/a
SaaS Platforms US Public Services Sector @connorgilbert N N n/a n/a
Mobile Mobile DevOps ?
Deploy Five Minute Production App ?
Edited by 🤖 GitLab Bot 🤖