ConductorOne provides identity governance and just-in-time provisioning for SonarQube. Integrate your SonarQube instance with ConductorOne to run user access reviews (UARs) and enable just-in-time access requests.
The SonarQube connector syncs active users, groups, global permissions (system-wide roles), permission templates (custom project-level roles), and projects with their permission assignments.This connector supports the following provisioning operations:
Users: Create new local users (with auto-generated passwords) and deprovision users via soft delete (deactivation)
Groups: Add and remove users from groups
Global Permissions: Assign and revoke system-wide permissions to users
Permission Templates: Assign and revoke specific permissions within permission templates to users (admin, user, codeviewer, issueadmin, securityhotspotadmin, scan)
Projects: Assign and revoke project-level permissions to users (admin, issueadmin, securityhotspotadmin, scan)
User deactivation warningWhen a deactivated SonarQube user is later reactivated (via SonarQube UI or API), they lose all group memberships and permission assignments. They are treated as a brand-new user. Only basic identity data (login, name) is retained. Plan reactivations accordingly.
The SonarQube v2 Users API returns only active users by default; the connector does not apply an additional filter on top of that. If the API ever returns inactive users, the connector represents them with a disabled status.
Grant expansion supported. When a group has a permission assigned via SonarQube UI (global or project-level), all members of that group automatically inherit that permission through grant expansion. Group permission assignments are read-only — they are synced but not provisioned through the connector.
A SonarQube API token generated by a user with Administer System global permission
Bearer token authentication (used by this connector) is only supported in SonarQube 10.0 and later. SonarQube Server versions prior to 10.0 are not supported.
The Connector Administrator or Super Administrator role in ConductorOne
Your SonarQube instance URL and the API token generated above
Cloud-hosted
Self-hosted
Follow these instructions to use a built-in, no-code connector hosted by ConductorOne.
1
In ConductorOne, navigate to Integrations > Connectors and click Add connector.
2
Search for SonarQube and click Add.
3
Choose how to set up the new SonarQube connector:
Add the connector to a currently unmanaged app
Add the connector to a managed app
Create a new managed app
4
Set the owner for this connector and click Next.
5
Find the Settings area of the page and click Edit.
6
Enter your SonarQube instance URL in the SonarQube URL field (for example, https://sonarqube.example.com).
7
Paste the API token you generated into the SonarQube Access Token field.
8
Click Save.
9
The connector’s label changes to Syncing, followed by Connected. You can view the logs to ensure that information is syncing.
That’s it! Your SonarQube connector is now pulling access data into ConductorOne.
Follow these instructions to use the SonarQube connector, hosted and run in your own environment.When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with ConductorOne, automatically syncing and uploading data at regular intervals. This data is immediately available in the ConductorOne UI for access reviews and access requests.
Create a namespace in which to run ConductorOne connectors (if desired), then apply the secret config and deployment config files.
2
Check that the connector data uploaded correctly. In ConductorOne, click Apps. On the Managed apps tab, locate and click the name of the application you added the SonarQube connector to. SonarQube data should be found on the Entitlements and Accounts tabs.
That’s it! Your SonarQube connector is now pulling access data into ConductorOne.
The connector supports 4 project-level permissions for provisioning: admin, issueadmin, securityhotspotadmin, and scan. The user (Browse) and codeviewer (See Source Code) permissions are not supported for provisioning because:
For public projects: These permissions are implicit — all users automatically have access.
For private projects: Access is controlled by project visibility settings.
Note that user and codeviewerare provisionable at the permission template level. Permission templates apply these permissions to projects when the template is associated with a project, rather than assigning them to individual projects directly.
SAML and federated users are synced as read-only. Group memberships and global permissions can be assigned to these users, but the connector cannot create or delete federated user accounts.
When creating new local users, the connector generates a random password with a minimum length of 12 characters (longer if the configured credential policy requires it). The password may include special characters. Instruct new users to reset their password on first login.