When signing up with a Gitlab at the org level, SonarCloud requires the access token to have api scope, as mentioned here Getting started with GitLab
SonarCloud requires that the access token have api scope. This gives SonarCloud more access rights than strictly necessary, but due to the lack of more fine-grained access control in GitLab, it is the only viable option.
To mitigate this potential security concern, we strongly encourage you to add a technical user to your organization, log in to SonarCloud using that technical user, and use the access token of that technical user to connect your GitLab group to SonarCloud.
SonarCloud will always limit its actions to those required for effective integration with GitLab and will never use the full access right provided by the api scope.
Can someone provide a technical justification for such a broad scope? My understanding that the API level of access does allow superuser admin creation, as well as revoking permissions to the existing users, so this is really is a nuclear option. Why does SonarCloud need this, and how the proposed technical user can mitigate anything? Can someone provide a more detailed explanation of the security aspect of using a dedicated technical user to reduce the exposure? Do you limit the scope of responsibilities to the technical user afterward?
SonarCloud requires that the access token have api scope. This gives SonarCloud more access rights than strictly necessary, but due to the lack of more fine-grained access control in GitLab, it is the only viable option.
Are you looking for the actual calls that can’t be completed without api access?
Ann,
I guess I really want to know what API requests SonarCloud is performing, and how creating a separate technical account will mitigate the risks.
Thank you for a quick response,
Ann, more specifically, for the recommended technical user could we select a Guest Role? What is a minimal setup for this technical user that will satisfy all integration with SonarCloud?
While read_user and read_api could get us pretty far for being able to handle authentication, create repositories, read information about pull requests… there’s no API scope that lets us decorate pull requests with information (leave a comment) except for api.
(While we have no plans today, nor have they been tested, I am curious if those limitations would be blocking for you).
I imagine we recommend the use of technical users because they are easy to quickly disable in the event of an incident, and can be more tightly controlled. People typically also don’t want their own user to be tied to PR comments, and the integration shouldn’t fail if somebody leaves the company.
I hope this helps a little in understanding why we require the permission scope we do.