Preventing Sonarqube Token Leak on Sonarqube-GitLab Integration

Hello everyone.
I am currently trying to integrate Sonarqube with my Gitlab Instance.
I want all project in my Gitlab Instance to be able to use Sonarqube as part of their Gitlab CICD pipeline, without each of them being able to access each other’s Sonarqube reports/results.
But all of the guides and tutorials (eg https://docs.sonarqube.org/latest/analysis/gitlab-cicd/) that I found seems to indicate that I need to write the Sonarqube Token in one way or another that is visible and/or reusable across projects. For example, if I told all of the project maintainers to set the SonarQube token in Gitlab environment_variable, they can use it to access each other’s report directly.

I came up with the idea of creating a unique account for every project or project maintainers and limit the access of each of those account to only of their own respective projects. But, I am not sure if this kind of ‘account-project’ authorization is possible or available in Sonarqube. Also, it requires lots of effort in creating an account every time a new project is being creating.

How do you think should I approach this problem?

Sorry if it turns out this problem is supposed to be a Gitlab CICD problem. I am still quite unfamiliar with features available in Gitlab CICD and Sonarqube.

Thank you.

Hi,

So… first, I think it’s worth noting that you can’t access the UI with a token. That means that even if I have the token to analyze your project, I won’t be able to browse it via the UI. Of course, I might still be able to pull values using the Web API, but that requires a lot of effort.

The next thing to note here is the difference between the Execute Analysis permission and the Browse permission. Let’s say you create a technical user, we’ll call it ‘Robot’ and give it analysis permissions on every project but nothing else. That means it has the ability to pull the settings required to run the analysis and to submit the analysis, but not the ability to read measures or source code. So even if I somehow manage to steal Robot’s full credentials and log in as it, I still won’t be able to browse my rivals’(?) projects.

Yes, this would work. And as you note, it’s a lot of labor.

Sure! You can create as many “technical” accounts as you care to manage. :joy:

You’ve probably deduced this already, but I think your best bet here is to create Robot. :smiley:

Actually, there might be something to note here… I believe you pay for GitLab by seats…? (I really don’t know. I’m extrapolating based off of some other community threads.) & so you probably don’t want to create a Robot-per-project, but only one central Robot just to keep your licensing costs reasonable.

 
HTH,
Ann

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.