I have a requirement to restrict the user/group to specific project only when the user belongs to that group login to sonarqube.
other members belong to other groups must not be able to see this project, but should be able to see their own projects. How to restrict like this?
Create the project in sonarqube.
A group should own this project, but should be visible only by them.
other group members should not this project.
can we apply permission template to the project remotely suppose from jenkins?
currently we use LDAP based authentication with active directory as follows =
several AD groups with their sibling groups in Sonarqube (same name, case sensitive)
Sonarqube permission templates with regex for the project key namespace,
i.e. com\.foo\.bar.+
when the AD Sonarqube admin group and the builtin admin user have all permissions
one group has read permissions for all Sonarqube projects (browse and see source code),
think of random checks by security team
1 - n Sonarqube groups (mapping the AD groups with the same name) get browse and
see source code permissions
Normally you use a technical user with your CI server (Jenkins …) that has permissions to create
projects, so no need to create projects manually. Our Jenkins user is even in the Sonarqube admin group, because we’re using the Sonarqube web api in our pipelines.
That is achieved with permission templates, see
No need for that, as permission templates are automatically applied at project creation
by Sonarqube server.
Thanks Gilbert for your reply. I have below challenges.
We are setting the name of the project in sonarqube based on the repo name (extract the repo name in groovy code in jenkinsfile and pass it during scanning)
So we dont know the name of the sonarqube project before and we can’t use that in the permission template to assign automatically.
Can we assign the permission template directly to the project when the project is created? and can we restrict it to a group during this process
We can set the project to private during its creation from the Jenkins pipeline?
What kind of restriction we get when we make a project as private?
I have some confusion on this. Could you pls help me on above questions?
Automating with permission templates and regex is only possible if you use some naming scheme,
i guess your reponames are using a naming scheme, something like project_subproject, i.e. foobar_frontend, foobar_backend or similar !?
Yes, that is possible via web api api/permissions/apply_template
We dont know the name of the repo before, it could be anything and not enforcing any naming standards. That is the reason we
could not use the regex pattern.
I will check this webapi. How can we associate a group to this project (from jenkins pipeline and from sonarqube UI), so that only these members should be able to use that project? By the end, project should be created, apply template to it and then associate a group to restrict to that project. this is the goal.
Unless we provide the proper permissions others won’t be able to see the metrics, source code … etc right? the project is visible to the people who have the permission on the projects right?
We would like to automate onboarding of users to sonarqube. Based on your experience Could you provide the suggestions to me how to onboard the user to sonarqube so that
proper issolation should be there between teams and among the teams there should be two types of groups one should be like admins, others should be like
users of the projects
Using permission templates makes no sense without a naming scheme.
I strongly advise to use one combined with permission templates, everything else will be a maintenance nightmare.
If you’re using LDAP based authentication and group mapping (the same group name in AD and Sonarqube), a user will get member of the related Sonarqube group after login.
With api/permissions/add_group and parameters permission and projectid it should be possible to give a Sonarqube group access for a project, but i never used it.
yes.
From my experience, it’s best to use AD groups (one admin group, one read all group,1…n developer groups) combined with permission templates - works like a charm.
But this requires a naming scheme.
In general automation only works with (naming) conventions and rules.
If your Jenkins user has sufficient permissions, a sonarqube project is automatically created.
Our Jenkins user has admin permissions, because we have to create the project with
special settings (new code setting, name of the main branch … etc.) via web api.
You might use a similar approach, see
one admin group, one read all group,1…n developer groups
Have you created these groups manually or with automation (if automation how?) ? For the above groups will there be separate permissions templates, Will you create these templates manually or automated (if yes How?)?
in the past, there were many departments that were only responsible for their respective area of expertise.
Nowadays you have teams with members from different departments.
So recently we’ve started to create AD groups like
DevToolChain-xxx-Sales
DevToolChain-xxx-Mobile
…
when XXX is the name of a project or similar and we use it for all tools as Sonarqube, Jenkins, Nexus, NexusIQ … etc. I’ve created the related Sonarqube groups manually, but it would be no problem to automate that via Sonarqube web api.
Then there is an onboarding process for new colleagues to get all their tools (IntelliJ, Eclipse …) and permissions for one or more DevToolChain AD groups, those requests have to be unlocked by the team leaders/product owners.
After that, developers are automatically added to these groups and have all necessary permissions and tools.
There’s no automation for the Sonarqube admin and read all group, this is done manually.
The Sonarqube read all group is for our security team members and some developers responsible for styleguides.
So far the automation, but right now, the permission templates are still created manually on demand.
When requests for new Sonarqube project namespaces increase, i will automate that via Sonarqube web api too.
we have only hosted inhouse projects, so your case might be different.
You will need one admin group for all, to do the maintenance, configuration for your Sonarqube instance and give support to all customers.
Don’t know if one read all groups makes sense for you, if you have different customers that are independent from each other.
If this is the case i would go with several groups like customerX-developers (browse and see source code) and maybe something like customerX-leaders that have more rights like adjust project settings …
Then beside that use permission templates with the developers and leaders group for each customer.
Yes, currently this still happens on demand.
If more requests come in i’ll automate via Sonarqube web api and integrate it into our selfservice portal,
which has provisioning services for git repos, nexus repos, jenkins folders … etc.
We have decided not use the LDAP user token for performing sonar analysis.
So we have created the local user account in sonarqube and generated token. By default this user belong to SonarUsers Group.
If we provide this user to team, they will be able to login and check the other projects also as the sonar users have the default permission(includes browse and source code also)
Want to disable the sonarusers group where the local user gets default level permissons. If we provide this user/password to teams, they should be able to see other projects as well. Want to avoid this.
What are the permissions required for token to perform the sonar analysis without any issues?
Want to know way to disable the Sonar Users group. Any challenges do I face if I do this?
Creating an equivalent groups and adding local users to it would be helpful?
the sonar-user group is a builtin default group that can’t be deleted / inactivated.
I never used local groups in Sonarqube, means i’m not able to help you with that.
If you have a Developer or Enterprise edition, you should contact Sonarsource support, they
will surely help you.
