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.)
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 groupMAINTAINERS
. For instance, we will bring about a breaking change such that groupMAINTAINERS
can now add/delete/update members in groups, and this is in line with how projectMAINTAINERS
currently behave. - We will remove some permissions from project
MAINTAINERS
and give it to projectOWNERS
. For instance, we will bring about a breaking change such that only projectOWNERS
will be able to create deploy tokens for projects from now on, and this is in line with how groupOWNERS
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
andOWNERS
will have similar permissions. The only exception is -MAINTAINERS
won't have any permissions regarding creating, deleting or updating other members toOWNER
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
orMAINTAINER
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 Yes for groups, add Y 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 columnAre 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 | ? |