Add membership webhook trigger for Project Membership Changes
Problem Statement (Background)
Our organization performs audits to the membership for Groups and Projects in order to ensure that we comply with access restrictions. While the list of Owners/Maintainers for the projects is restricted to a minimum to avoid incorrect access being provided, we are still required to audit the access (In case of mistakes).
We have created tools that can trigger based on the Group Membership Event Webhook. When triggered, a pipeline checks and makes a determination of whether the user is in an approved list (Hosted outside GITLAB) to access certain group. The verification is made within 15 seconds, and the user is removed if access is found to be not approved.
However, for projects it is not possible to Trigger an audit of the Membership because the Membership Event Webhook is not available at the project level. In addition, the Group Membership Event Webhook does not get triggered based of a Project Membership change.
As a result, we have had to build pipelines that are constantly querying the API for the membership of each project every hour (during this time we would be exposed to granting unapproved access).
With this proposal, we would have a trigger that can inform of changes to a Project Membership so that we can create a pipeline to audit the changes in Membership
Proposal
To add a Webhook that triggers due to Membership Events inside a Project.
From Documentation These events are triggered for group webhooks only.
Member events are triggered when:
- A user is added as a group member.
- The access level of a user changes.
- The expiration date for user access is updated.
- A user is removed from the group.
How it will work
Option 1:
The Group Webhook can be expanded so that it gets triggered if:
- A user is added in a project inside the group
- The access level of a user changes in a project inside the group
- The expiration date for user access is updated in a project inside the group
- A user is removed from a project inside the group.
Option 2:
Another idea would be to create instead a Project Webhook that gets triggered by those events, instead of driving the complexity of dealing with Membership Events from the group where the project is stored
The Project Webhook can be expanded so that it gets triggered if:
- A user is added as a project member.
- The access level of a user changes in the project.
- The expiration date for user access is updated in the project.
- A user is removed from the project.