Start Free
10.7 | Instance administration | Authentication and provisioning | GitLab | Provisioning modes | Automatic provisioning

GitLab automatic provisioning mode

On this page

Starting from the Developer Edition, you can enable the GitLab automatic provisioning mode in SonarQube and benefit from:

  • Automatic user and group provisioning and de-provisioning.
  • Automatic synchronization of users' group memberships.
  • Automatic synchronization of user permissions on projects.
  • Automatic project visibility synchronization.

Limitations

You can enable automatic provisioning only with one identity provider. It means that you can only use Just-in-Time provisioning with other providers.

The permission synchronization concerns only the project-level permissions. It means that you must still configure the global permissions manually.

In the automatic provisioning mode, the actions you can perform on local users are restricted (Local users are all the users that are not managed through the automatic provisioning process, i.e. manually created users or through another identity provider Just-in-Time-provisioned users.):

  • You cannot change user passwords.
  • You can remove but not add a project's permissions to local users. However, you can still define default project permissions with the permission templates.
  • You can remove but not add local users to a local group.
  • You can still deactivate local users and remove local groups.

In addition, you cannot manually create users.

User and group provisioning

The user and group provisioning is restricted to predefined GitLab root groups (groups with no parent): only members of these groups and all their subgroups are provisioned. These groups and subgroups are called Allowed groups. 

On an hourly basis:

  • SonarQube provisions and de-provisions the groups as follows: 
    • For each Allowed group that doesn’t exist yet in SonarQube, it creates the corresponding group: see Group creation below.
    • It removes any existing group in SonarQube that doesn’t belong to the Allowed groups.
  • SonarQube provisions and de-provisions the users as follows:
    • It creates a user account for any member of an Allowed group who doesn't have yet an account in SonarQube.
    • It removes any user account that doesn’t belong to any Allowed groups. 
  • SonarQube synchronizes the users with GitLab regarding:
    • Group memberships.
    • Project permissions: see Project permissions synchronization below.
  • SonarQube synchronizes the visibility (public/private) of each project with its bound repository’s associated project in GitLab.

In addition, if enabled, SonarQube synchronizes the group memberships of any existing auto-provisioned user at authentication time (Just-in-Time (JIT) synchronization). 

Group creation

Since SonarQube doesn’t support the group hierarchy (there is no subgroup concept), the corresponding groups and subgroups are all created in SonarQube as groups.

The following naming convention is used for a group:
<rootGroup>/<subgroup_1>/<subgroup_2>
where:

  • rootGroup: is the name of the root group (group without parent) in GitLab.
  • subgroup_i: is the level_i’s subgroup name in GitLab.

For example, if the GitLab group URL is https://gitlab.com/my-gitlab-group/my-subgroup, the group name in SonarQube will be my-gitlab-group/my-subgroup.

Project permissions synchronization

With the automatic provisioning mode, the user permissions on projects are also synchronized: for each project, the permissions of auto-provisioned users are synchronized in SonarQube based on the highest GitLab user role applying to the repository in GitLab and according to the configured role permission mapping. A default mapping is provided but you can change it to adapt it to your needs. In addition, if you manage GitLab custom roles (with GitLab Ultimate), you can configure the permission mapping of the custom rules in SonarQube.

Default role permission mapping

The table below shows how a GitLab role is mapped by default to a SonarQube permission at the project level (For more information about project permissions, see Permissions related to a project in Managing user permissions).

GitLab roleBrowse ProjectSee source CodeAdminister IssuesAdminister Security HotspotsExecute AnalysisAdminister Project
Guestx




Reporterxx



Developerxxxxx
Maintainerxxxxxx
Ownerxxxxxx
Custom GitLab roles

You can define the mapping of your custom GitLab roles to SonarQube permissions. If no mapping is defined for a custom role, SonarQube will perform the permission mapping based on the custom role’s inherited base role.

Project visibility synchronization

With the automatic provisioning mode, the SonarQube project visibility is synchronized with the visibility of the project associated with the corresponding repository in GitLab according to the mapping table below. 

GitLab project visibilitySonarQube project visibility
PrivatePrivate
InternalPrivate
PublicPublic

Was this page helpful?

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License