Is it possible to delegate the deletion of projects in sonar to users ?
Knowing that the authentication of my sonar is managed by an ldap directory.
Thanks.
In SonarQube, project administrators have the right to delete the projects. So if you want to delegate deletion of projects to users, you must make sure that those users are granted Admin rights on the relevant projects.
As you are using an LDAP, you can do the following:
At global level, create one group per project called (for instance) "admin_projectName" (replace "projectName" by each project name)
In your LDAP, set the "admin_projectName" group on every user who should be project admin of a given project
Configure the LDAP plugin to synchronize the groups (called "Group Mapping")
Related
Sonar Server 6.7.1.
I have following queries wrt how permission works in SonarQube
1. How to enable window NT authentication on sonar portal. I believe by default it is open to everybody, no authentication.
Using sonar admin account I can create the quality profiles (add/remove rules) & assign it to a project. Can I do it as project admin account as well? My use case is I have couple of projects hosted, I do not want to share admin account with each project.
I created many users and groups on sonar portal, but I could not see them under Global Permission page. How to projet administrators?
Let's say I have set of issues reported by sonar for a project. From the portal I want to mark some of the issues as "Won't fixed". What is the minimal permission required user/project admin/sonar admin to do it?
Appreciate your response on above queries.
Disable anonymous access: Disallow anonymous users to access Sonar
You need Administer Quality Gates global permission
You have to start typing username you are looking for in Search field
You need Administer Issues project permission
Please take a look at SonarQube documentation: https://docs.sonarqube.org/display/SONAR/Authorization
How to view authorized list of users and groups configured for a project in Sonarqube 6.7? (feature was there in earlier versions of Sonarqube (refer screenshots))
We have recently migrated from Sonarqube 4.5 to 6.7 and in v4.5 access for few projects were configured using template and for few it was configured directly without template. Now after migration we are facing access issue for many projects. Before applying new access template to such projects we would like to view current settings but Projects Management page list only 2 options; Restore Access and Apply Permission Template. Here we want to understand,
Current access configuration
Access configuration that Restore Access option enables
Permissions web services too is not listing any api to fetch project wise users/group configuration.
From the Project homepage, go to Administration > Permissions. There you can see the groups and individual users granted permissions on the project and update those settings.
I'm using Nexus Repository Manager 3.1.0-04, and I want to create a user to just have deployment permissions. What are the minimal set of privileges required for that?
Right now I created a role nx-deploy with the following privileges:
nx-repository-admin---read
nx-repository-admin---browse
nx-repository-admin---delete
nx-repository-admin---edit
nx-repository-admin---add
Then I created a user deployment with the role nx-deploy. I can deploy artifacts now, however, I believe I am giving too much privileges? The admin part is not what I want the deployment user to be, so that part has me a bit nervous.
Needless to say, there are just too many privileges to choose from under the security section.
The general rule is nx-repository-admin privileges are for administering the repositories and their details; nx-repository-view privileges are for use of the repositories once set up. Assign the latter.
To tweak repository privileges of your Deployment user(s) you should use the nx-repository-view-*-*-* as the assigned privilege, instead of nx-repository-admin. So, remove all the privileges you addressed in your question, and replace the ‘Given’ field with nx-repository-view-*-*-*. Since the privilege is denoted with asterisks, your Deployment users can perform all the above actions (i.e. browse, read, edit, add, and delete).
See the screenshot for reference:
Configuring the nx-deploy Privilege for the Deployment Role
You can read more about Privileges in the Security chapter: https://help.sonatype.com/repomanager3/security/privileges
If you need minimal privileges to just deploy artifacts, nx-repository-view-*-*-edit is enough.
nx-repository-admin is used for administration and configuration
Repository Admin
These are privileges related to the administration and configuration of a specific repository
and edit is enough to modify repository content
edit
This action allows privileges to modify associated scripts, repository content, and repository administration.
BTW, you need nx-component-upload to upload components in web UI.
https://help.sonatype.com/repomanager3/user-interface/uploading-components
Successful deployment by maven 3 with Nexus 3.8.0 the following rights are required
nx-repository-view-*-*-edit
nx-repository-view-*-*-read
nx-repository-view-maven2-maven-snapshots-edit
nx-repository-view-maven2-maven-snapshots-read
"maven2"is recipe,"maven-snapshots" is your repository name.
I am new to SonarQube and trying to setup up a proper access control, with requirements as follows:
We have a few project areas, each area should have someone able to
manage their area, such as creating new projects and manage the
boards, not sure exactly what. This is something like project area
administrators.
A few administrators can do anything.
Integrate to AD
A few questions:
In a few places like this link: http://www.sonarsource.com/products/features/security/, I see this role based method, but I can't find these default roles, "SonarSource products come with three project-specific roles – project administrators, project users and project code viewers" anywhere in the system. Right now, I am using the community edition I guess without a license. Is there any more detailed document on that?
I kind of understand the default Global Permissions and Project Permissions. In my case, shall I create e.g. three groups in AD, sonar-administrators,sonar-project-administrators, sonar-users to map to the default groups?
I notice the following: right now I don't have the above AD groups, when I integrate to AD, I can login with my domain id/password, but once logout/in, the group information I added to the local user gone. I guess it sych with AD. So to use AD, I have to create these groups in AD?
Jirong
Access control in SonarQube is managed through Global Permissions and Project Permissions. Each permission can be granted to user(s) and/or to group(s). The documentation you pointed at is quite outdated, read the Authorization page for the most up to date details.
AD/LDAP integration is a different topic, documented here. With group mapping, group membership stays managed in AD but will be replicated in SonarQube when users log in (the AD groups must first be created in SonarQube with the same name).
To your example: if AD users belonging to group foo deserve to administer your SonarQube, just create group foo in SonarQube, and (in the Global Permissions settings) give Administer System permission to group foo.
I have installed Nexus 2.0.6 and the integration with my LDAP server is working (authentication only). Is there a way to configure Nexus so that only a set of developers are able to deploy a given artifact, or group?
I basically do not want a developer in Team A deploying an artifact that Team B is reponsible for.
You may partition a repository using repository targets, privileges, and roles as described in this Sonatype blog post. I tested this a few months back and it seemed to work well.
Under Nexus 2.0.1, this is the solution that I've worked through and verified.
Caveats:
This allows one to restrict the "Artifact Upload" option to a directory hierarchy.
This is not quite the same as "deploy" or in conjunction with "release prepare".
Steps:
Remove the single privilege of "Artifact Upload" from all that presently have it, that you do not want to have it.
Create the "Repository-Target" that includes the directory mask of where you want to give access. Ex. .*/com/mycompany/target-dir/.* Double check the mask, it starts with period-asterisk AND ends with period-asterisk.
Create the "Repository-Privilege" that maps to the Repository-Target you just created. Typically I include the repo-name in this repository-privilege-name, like "releases.com.mycompany.target-dir". This creates the CRUD entries (4) for said directory.
Next, create the "Role" based on the Repository Privileges you just created (4), plus "Artifact Upload". Total of 5 entries for the role. Use the "Apply Filter" here to help you find these items. I name this role something like "Upload.Role.Releases.Target-Dir". Again, when finished there should be 5 entries for this role:
Artifact Upload
com.mycompany.target-dir(create)
com.mycompany.target-dir(delete)
com.mycompany.target-dir(read)
com.mycompany.target-dir(update)
This is what constrains the upload role to this repo.directory.
Create the User if it does not already exist, assign password.
Give the user the following Roles:
Nexus Deployment
Repo: All Maven Repositories(Read)
UI: Base UI Privileges
Upload.Role.Relases.Target-Dir
Hit save and you've got it. Later on, you can use this same approach to create a new Role for other repos (say Snapshot or 3rd Party), and keep the same directory mask.