Admin Privileges and Permission Behavior with GitHub Automatic Provisioning

SonarQube Server / Community Build
,
1

Hello,

We are using SonarQube Server 2025.6.1 (helm deployment) and have enabled Automatic user, group, and permission provisioning with GitHub.

After enabling this feature, we noticed the following behaviors and would like clarification:

  1. Admin privileges

    • Once GitHub automatic provisioning is enabled, the admin user loses administrator/system-level privileges and no longer has access to all projects.

    • This issue mainly affects projects created after GitHub provisioning is enabled, where the admin user does not automatically get access to newly created projects.

    • We would like to keep at least one user with full system/root admin privileges with access to all existing and newly created projects, even when GitHub provisioning is enabled.

    • What is the recommended way to achieve this?

  2. GitHub Owner visibility

    • GitHub users with the Owner role cannot see all projects in SonarQube.

    • In role mapping, only read / triage / write / maintain / admin roles are available (no Owner role).

    • Should GitHub Organization Owners be added to specific Github groups to gain full project visibility?

  3. Existing project permissions after enabling provisioning

    • We noticed that users who already had project-level permissions before enabling GitHub provisioning keep their old permissions, including access to project settings.

    • We expected these permissions to be overridden or removed after syncing with GitHub.

    • Is this behavior expected?

document reference that we followed : document

Thanks,

2

Hi

So to be clear, it’s not that the administrator loses access to existing projects. It’s that they’re not granted access to new projects.

How are these projects being created? Is the admin user creating them, either manually or via script? Or is a technical account being used to create them? I ask to know who would get any “creator” rights assigned by your permission template.

To whom does your permissions template grant access to new projects? Only the creator? Certain, specific groups and individuals? Is the admin one of those individuals or in one of those groups?

 
Ann

3

Hello Ann,

Thank you for your answer.

We are using the default permission template, and our projects are created automatically via a script using a GitHub user (this user was part of the sonar-administrators group).

Currently, admin access to new projects depends on GitHub provisioning and the permission template.

However, we also need the ability to assign full SonarQube admin access to some users at the server level even if they do not have equivalent permissions in GitHub.

Is there a supported workaround or recommended approach to allow certain SonarQube users to retain system admin access independently of GitHub role mapping?

Thanks.

4

Hi,

To be really clear, you’ve turned on SCIM provisioning, right? Because per the docs:

When you enable automatic provisioning through SCIM, all users and groups become read-only in SonarQube Server.

This means that if you want a user/group to have a privilege in SonarQube they must have it in the system of origin.

 
HTH,
Ann

5

Hello Ann,

To clarify, we are not using SCIM and have enabled GitHub authentication with user, group, and permission synchronization.

With this setup, we noticed that we cannot maintain the local/default admin user in SonarQube who can automatically has access to all projects, including newly created ones.

As far as we understand, the only workaround is to:

  • Create a GitHub group/team

  • Add the required admin users to that group

  • Then the new groups will have admin access to all the project in Server

Please confirm if this understanding is correct, or if there is another recommended way to keep a global/system admin in this setup.

Reference:
https://docs.sonarsource.com/sonarqube-server/2025.6/instance-administration/authentication/github#about-user-permission-synchronization

Thanks.

6

Hi,

SCIM is automatic provisioning, which is what you’ve pointed me to in the docs.

If that’s what you’ve chosen, it sounds like you might want to switch to just-in-time provisioning. Note that if you do this, you’ll need to manually

  • create your groups
  • delete users who have left your organization

 
HTH,
Ann