How to enable users belonging to group sonar-users see the analysis of the project done by the sonar-administrator? - jenkins

I have a community edition of sonarqube (version 8.8) setup running on GKE. I have created a public project using the Administrator user and running a jenkins job for python code analysis. Below is my sonarqube-scanner properties in Jenkins job:
sonar.projectKey=ws-python
sonar.scm.disabled = True
sonar.sources=./$branch/${BUILD_NUMBER}/backend/
sonar.language=py
sonar.host.url=http://<ip-address-of-sonarqube>
sonar.login=<project-key>
I created few users which by default belongs to sonar-users group and provided them the below access:
Upon successful analysis of the code, as an administrator user, I am able to see the dashboard with all the issues like bugs, vulnerabilities , security hotspots etc. But when I am seeing the same dashboard as any users belonging to the group sonar-users, I am unable to see anything in the dashboard. And I am getting below error:
Also, I have provided the access to all the users of the group sonar-users for the project.
Can anyone help me how I can make these projects accessible to all the users?

Related

Jenkins Role Based Authorization Strategy Plugin Inconsistent behavior for different users

Current State: I have implemented project based roles strategy (also called the item roles) and have the appropriate project folder level regex etc set up. And I have verified the regexes and other permissions work fine for most logged in users, except the below scenarios I am running into.
Plugin Version: 3.2
Jenkins Version: 2.263.4
Jenkins Authentication Provider: LDAP Connecting to Active Directory
Example regex(es): for project role dev = ^ABC\-DEF\/DEV\/.*
Issue: Certain users are only having issues while going through the project role based authorization plugin where they are not able to see the option to run builds or job configurations. While the same configurations work for a couple of other user who have the same permissions.
Example:
Users - adm-XXXX and adm-YYYY and a few more all starting with the prefix of adm- are not able to get the roles for the configure and run builds on the jobs based on the above regex.
While Users - adm-zzzz and others are able to get the same roles using the same permission matrix.
The issue is very inconsistent as some days it would work, and even the same configurations when I tested in another Jenkins instance it worked for the user - adm-XXXX so I am at a loss on how to debug why it does not work for a few users consistently. I can understand if it is a configuration issue it should not work for all users having the same role.
Are there any tips on enabling some extra debug to troubleshoot this since there are literally a couple of loggers in the code of the plugin.
Appreciate the help here from any one knowledegable.
I have same issue, where associating an LDAP/AD user to a local global role or item/project role with build and configure permissions enabled does not enable this permission in the project itself. The option to build and configure is not available.
The only way I got around this was to add the users into AD groups and associating the AD Group to a role with required permissions.
Enabling the exact same permissions on the AD group role that I had on the local role, enabled the build and configure option in the projects.
I am not sure if this is a bug, an AD integration issue that you cannot mix/match local and AD roles or I am missing some option or if anyone has managed to get around this anomoly - but this workaournd seems to overcome this.

Jenkins 2.7.x Role Strategy Plugin

Using Jenkins 2.7.x I am trying to configure the Role based Strategy Plugin, but facing some issue.
Scenario is, there are 2 teams products I & P each can have Dev, Admin & Lead.
So created 6 LDAP (project) roles & one CI_Admin global role.
and assigned these roles to LDAP user group
Now when the admin logs in he gets error
What am i missing ?
I can see that in global roles in (Fig 3 Highlighted in the below image) read permission is missing. so to login to Jenkins user/group should have read permission.

How to grant access to 'All-Projects' project for only Administrator in Gerrit

I have setup a Gerrit server in an Ubuntu server (Ubuntu 16.04 LTS).
Gerrit version: 2.14.6
Now the question is, for some reason I would like to configure Gerrit that only Administrator users will able to view/clone/modify 'All-Projects' and 'All-Users' projects. No other users like 'Registered Users' will not able to access.
All other projects will be visible to all users like registered users or specified groups.
Is there any way to perform this operation?
Note:
If this question is redundant, please forward the right place.
You can grant:
refs/* Read ALLOW
only to Administrators in All-Projects project, but you'll need, of course, grant the required read permission to the other users/groups to all repositories. To facilitate the setup you can have an inherit struture (using the "Rights Inherit From" feature) like the following:
All-Projects
Public-Projects
xxxx
yyyy
Private-Projects
wwwww
zzzzz

How to restrict in Jenkins users from viewing users information like: id, name etc

I have configured Jenkins on centos 7.
Being administrator, I have created few users and gave them permissions to their projects like: build, read etc.
I have used a Project-based Matrix Authorization Strategy. Its working but I'm facing the following problem:
If any user clicks on people information (button on left is dashboard) then any user can view all the other users ids, name etc. I want to block this from happening and I can't find a solution to this problem.
Can it be a configuration problem?
Here is one solution using the Role Strategy plugin.
I'm using this plugin for our Jenkins server and it's really useful to define permissions.
On my staging Jenkins, I've create 2 users:
A full admin
A viewer
I've created 2 roles with the plugin:
Next, I assign the roles to the relevant users:
The viewer role only have a global read access + build on the jobs.
If I open a session with the admin one, I can see all the people:
With the viewer user, I don't see anything:
UPDATE:
If you want to assign some permissions on a specific project, you can create project roles (in the Manage Roles section):
You can filter the projects with a regular expression:
job(.*)postcommit
Next, in the Assign Roles section, you just have to assign the relevant project role to the relevant user.
I hope it helps :)

How to find out who changed the permission settings in Jenkins?

I am using Folder plugin and AD groups to control access to folder. This morning a team can't access their project anymore and later I found the AD group assignment in Assign Roles has been changed to wrong groups. Is there a way to find out which id did it? We only have a few admin ids.
Jenkins does not appear to keep an audit trail by default, as stated in this post on cloudbees.com, the folks that develop Jenkins.
The relevant lines:
Many Jenkins users look for a recommend a strategy for keeping an audit trail. This article is supposed to be a gap filler until more comprehensive compliance capabilities in JE/JOC are developed.
There are two open source plugins that enable you to track “WHO did WHAT?” in Jenkins:
...
The first plugin listed is Audit Trail Plugin which looks to provide exactly what you are seeking.
The description from the plugins page:
Keep a log of who performed particular Jenkins operations, such as configuring jobs.
This plugin adds an Audit Trail section in the main Jenkins configuration page. Here you can configure log location and settings (file size and number of rotating log files), and a URI pattern for requests to be logged. The default options select most actions with significant effect such as creating/configuring/deleting jobs and views or delete/save-forever/start a build. The log is written to disk as configured and recent entries can also be viewed in the Manage / System Log section.
I spent a few minutes looking through Jenkins various xml and log files, but could not find a log that contained something useful (username and/or timestamp). In this case it seems user auditing isn't built into Jenkins as of yet. Unfortunately it appears that you might not be able to determine who made those changes after the fact.

Resources