Global Read Permission for API-invoking Admin-like User

SonarQube Server / Community Build
1

I read this thread which answers this question in some sense, but I’d like to elaborate on the request for a read-only administrator-type user by adding my specific use case. I have a service account that is used to execute API calls to automatically retrieve information on all private and public projects hosted on the server instance. At present, it’s a global administrator, which is overkill given it doesn’t write or update any information - nor would I want it to. All it needs is global read privileges to trigger API calls on projects like e.g. retrieve the project analysis, retrieve the code coverage for a project, or load specific rules from the server to retrieve vulnerability data, etc.

Is there no appetite for some form of global read, or is there some workaround to achieve this? I had also seen this other thread, but I’m not sure it’s applicable in this instance as I don’t want to set all projects to private. How would that workaround work if all projects were public, for example?

2

Hi,

I think I can guess, but could you elaborate on why you want to read everything? I guess you’re porting data into some other dashboard or reporting tool?

 
Thx,
Ann

4

That’s it. We have setup webhooks from all projects but their payloads are a little light. However, the fields within can be used in construction of subsequent API requests e.g. project ID for the export_findings endpoint, which in turn contain the level of detail required for meaningful reporting e.g. coverage. It’s those subsequent API requests that require global readership.

1 Like
5

Hi,

Thanks for the detail. I’ve flagged this for the PMs.

 
Ann

8

Thanks for your input, @dbeezt. I’ve taken note of your request, and it will be considered as part of our prioritization process.

I’d like to clarify one point: would an instance-level token with browse all permissions address your need?

Thank you.

10

From the permission docs: “Browse : Access a project, browse its measures and issues, and perform some issue edits (confirm, assign, comment)”. It does sound like the right permission, although the editing of issues doesn’t sound read-only to me.

The docs state that each new project is created as public, meaning everyone has browse permission against it. There is also the “Browse Project” permission from here, which infers that private projects must explicitly be given a separate Browse permission. Would your suggested “Browse All” permission override the need for private projects to opt-in to being browseable?

At the end of the day, if there was a less destruction-capable role that could be used to trigger API events, I’d be happy.

1 Like