[CentOS-devel] GitLab AMA Topic Discussion: Permissions & Access

Sun Oct 25 21:21:06 UTC 2020
Aoife Moloney <amoloney at redhat.com>

Hi everyone,

Thanks again for your involvement in the GitLab AMA session on IRC in
September. As promised, this is the first of a 5-part series breaking
down main topics that came up during the session. I will send a topic
every week for discussion to both Fedora and CentOS devel lists. While
this may not impact CentOS directly right now, there may be some
crossover  in the future, such as the merging of the CentOS account
authentication system to be under the same software as Fedora, and I
want to make sure you are all kept aware of developments too. So, I
have pulled the relevant questions and answers from the original
hackmd doc into one email. If you would like to discuss this topic
specifically, here might be a good place to do so. I dont consider
myself technical enough to weigh in on details, but I am happy to
facilitate as best I can via email. And more importantly (for me),
learn from the discussion too.

Here are some links to resources as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
* AMA Blog post
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
* Here is this email in hackmd if you wish to view it there:
https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view

## Topic: Permission and Access

- Question: Fedora has a group-based access system. People in the
`packager` group have (commit) access to only the packages they
maintain. People in the `provenpackager` group have (commit) access to
all the active packages, but a few (for legal reason). People in the
`releng` group have commit access to all the packages. Is this an
access model that GitLab can support? If not, how would this work in a
GitLab world? How would notifications work (Esp consider people in the
`provenpackager` or `releng` group do not want to be notified for all
the projects they have access to)?
    - Answer: What I explored was something along the lines of :
        - Packager → Using GitLab’s Maintainer or Developer role for
the project they maintain (Maintainer have the ability to access
project settings and change pretty much everything there, so that
might be blocking here, Developer only have commit access, so we need
another way to change some settings for Packagers)
        - Co-Maintainer → Using GitLab’s Developer role (commit access)
        - Proven-Packager → GitLab’s Developer role on all repo (expect 2)
        - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos
        - This is not an exact matching with what we currently have
but should give us a way to experiment with this and look at what is
acceptable or not.
        - There is also a GitLab ticket
(https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement
policies for the project that could give more granular control of
permissions.
        - Gitlab’s notifications are quite granular and can be managed
at the different levels (Merge Requests, Projects, Group, Global)
https://docs.gitlab.com/ee/user/profile/notifications.html#global-notification-settings


- Question: Fedora supports the concept of a retired `project` (ie:
archived) that no-one can commit to. Does GitLab have an equivalent
concept? (The retired status is not something project admins can
change)
    - Answer: There is an option to have a “retired” group which is
configured to have nobody with commit access. Then retiring a project
would simply mean to move the project from the “rpm” group to
“retired” group for example.
There is also possibility to simply archive projects
https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project

- Question: could gitlab (inc) maintain a Community Edition GitLab
instance that Fedora uses?
    - Answer: There is no plan to create custom versions of GitLab for
customers. Instead, GitLab encourages paid customers and free users
alike to contribute upstream to make sure that GitLab continues to
work well for the most amount of users possible. As an open core
company, GitLab has a public roadmap and works with its community
members to build a great product.
GitLab regularly engages with its community and takes into account its
feedback. As a result, features are often ported down into lower tiers
in order to make the Community Edition and Free tiers continuously
more useful (see example of 18 features moved to open source). GitLab
hosting is available to users of GitLab.com SaaS, but GitLab does not
offer hosting and management for GitLab CE or EE instances.

- Question: Can project creation be restricted to a specific group of
people in GitLab?
    - Answer: Yes this can be configured at the instance level
(https://gitlab.com/help/user/admin_area/settings/visibility_and_access_controls.md#default-project-creation-protection)
or at the group level
(https://gitlab.com/help/user/group/index.md#default-project-creation-level)

- Question: Can project (main project, not fork) deletion be
restricted to a specific group of people in GitLab? (ie: project
owner/maintainer must not be allowed to delete a main project, they
can delete their own fork of course)
    - Answer: There is an issue
https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help
with this by requiring an additional person approve the deletion &
there’s a related issue
https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list
of authorized approvers for these types of changes (not MRs) that
sounds aligned with this ask

- Question: How would group membership be sync to GitLab?
    - Answer: We are still not 100% clear on that, since GitLab
supports OpenIDC & we will need to investigate if we could make use of
the group scope returned by AAA. Otherwise we will need a solution to
sync the groups to GitLab most likely using API calls.

 - Question:Will there be better support for Podman in CI workflows in GitLab?
    - Answer: Short term solution might be using a custom executor,
long term solution would be getting the Runner executor podman (#4185)
feature request issue scheduled and closed. Ultimately product team
schedules work, while everyone can contribute MRs or fixes ahead of
schedule. In the past, I've seen a lot of enthusiasm from GitLab team
members in helping solve problems from Open Source Program members
whenever possible.

These are all the questions that had answers I could spot from the
larger hackmd document, however my apologies if I missed any.
next week I will pull in all the questions and answers on 'Message
Bus' in a new email and send for discussion.
I know there are still some questions unanswered so I will try to
chase down answers to these, but it could take some time. If I can get
them answered over the next few weeks, I will send a 'misc' topic
email at the end of these few weeks worth of emails.


I hope you find this helpful and it is going to take some time to work
through everything so thank you for your patience and involvement in
this, it is very much appreciated.



Kindest regards,
Aoife
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford