We are looking to connect our Developer Edition of SonarQube to our pull requests, so that the quality gate in SonarQube can be used as part of the process (to allow/block the merge).
Our Cybersecurity team don’t really want to use a PAT because it would require one of the two below scenarios:
• creating a “shared build user” with no password expiry which the whole dev team will know/share/use in their pipelines
• linking the PAT to a “specific actual real user”, which if that user then leaves, their PAT will expire with no notification to anyone and the pipeline will “break” without obvious cause (until it can be traced).
We would like access between Azure DevOps and SonarQube Server to be linked to the person who is doing the work/access, and not have any common shared users in our system (to follow best practice for cybersecurity, a zero trust type logic).
A system to system token based service connection would be preferred.
Hi @synxnickdavies ,
we are using first approch with a dedicated build server account. Why should the whole team know the credentials? Only the Azure DevOps admins have access to the build user account. If really required you can create a variable goup in Piplines - Library with the user name and (secured) password.
And yes, you ned to extend or replace the PAT before it expires (make a reminder in the admins calender.)
We currently allow all Devs to be admins and to create/maintain/alter the pipelines. With a common build user and each person editing the YAML, they would require to know the credentials and we would not know which real user (it would always be the build user) had triggered the connection, and would also be able to login as the build user whenever they wanted (which would mask who was using it).
Assuming you are saying per this link that we have an IT admin create the variable using the build user (and do not give those credentials to our devs) and instead let them call the variable from each of their pipelines. It would still not link who triggered the connection to SonarQube, but I guess the build user would be secure as it would reside with IT in their internal key vault. I will have that discussion internally.
Yes @synxnickdavies, exactely this variable groups. Even if you have multiple build servers you can use common build account. Build accounts are one reason why we get 5 free accounts on Azure DevOps.
Why do you care, who did the build? The result should be independent of the user and not “works on my pc”. That’s an advantage of a dedicated build server. You can still see in the build logs, on which server and directory the build run - but it should be rarely used to investigate failing builds on the server. Better enable system diagnostics or export temporarily additional logs, … as artifacts.
In Azure DevOps you still see who created the PR, who committed and pushed code to the PR. Assuming that you’re using a git repo with the SCM in SonarQube for each line the last committer is indicated.
I’ve asked our IT/Infrastructure team to review, as it is they who have raised the concerns.
It would be good if the SonarQube product team could advise what their plans are for some sort of service connection or a federation of sorts, so that we could avoid having to mess around with PATs.
As you noted it does mean having a regular reminder and review of them to stop them expiring with notification/noticing.