GitLab automatic provisioning mode
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).
Automatic synchronization won't set or update emails (This is done at each user login.).
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.
With this feature:
- Project permissions are set at the user level only (not at the group level).
- Project permissions cannot be edited in SonarQube (Manually edited project permissions of existing auto-provisioned accounts get reset in SonarQube.).
- The application of default permissions for new projects through permission templates is not supported.
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 role | Browse Project | See source Code | Administer Issues | Administer Security Hotspots | Execute Analysis | Administer Project |
|---|---|---|---|---|---|---|
| Guest | x | |||||
| Reporter | x | x | ||||
| Developer | x | x | x | x | x | |
| Maintainer | x | x | x | x | x | x |
| Owner | x | x | x | x | x | x |
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 visibility | SonarQube project visibility |
|---|---|
| Private | Private |
| Internal | Private |
| Public | Public |
Related pages
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.
