Gitlab authentication group synchronization strict matching

SonarQube
1
  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarQube Enterprise Edition Version 8.2 (build 32929)
  • what are you trying to achieve
    Gitlab group synchronization to match strictly, not relatively.

Hi everyone, we are in the midst of evaluating the Sonarqube EE for our organization, in particular the group synchronization function with Gitlab.

Scenario:

Take for example a user “dev-A”, the account of a developer and “mnt-A”, the account of a maintainer. They are both placed in the following group:

“dev-A” is in group users/team-A/maintainer/developer
“mnt-A” is in group users/team-A/maintainer

To allow the group synchronization to take place, I have also created both of that group in SonarQube. What happen is that when I log in to SonarQube with “dev-A”, user “dev-A” is being added into both of the groups ( users/team-A/maintainer/developer and users/team-A/maintainer ), what I wanted instead is that “dev-A” should only be added into group users/team-A/maintainer/developer .

Question

I believe the relative hierarchy is doing something here and which leads to my question: is there any way to force the group mapping to match exactly as they are in Gitlab? E.g. user “dev-A” is in users/team-A/maintainer/developer and therefore in Sonarqube, “dev-A” should only go into group users/team-A/maintainer/developer, and not its “super” group users/team-A/maintainer

4

Hey, I don’t really think there is much we can do on the SonarQube side about this. For group synchronization we rely on GitLab membership definition:

https://docs.gitlab.com/ee/user/group/subgroups/#membership

When you add a member to a subgroup, they inherit the membership and permission level from the parent group.

So in your example, if you look at the membership of your “dev-A” user, on GitLab, this account is actually a member of:

  • team-A
  • maintainer
  • developer

technically speaking, SonarQube relies on what GitLab return for this API call that you can try with your different account:

https://gitlab.com/api/v4/groups

We use the full_path attribute to match SQ groups.

Unfortunately with GitLab, by overriding the ancestor group membership, you can only change the permission level (guest/developer/owner), but not the membership.

1 Like
5

Hi Pierre,

Thank you for the in-depth response with the reference links. I guess we can either change our group structure in Gitlab or be more lenient about the access control at our SonarQube instance. But that will be a separate internal discussion.

Thank you once again and have a great day ahead!

1 Like