what are you trying to achieve
Establish functional DevOps configuration for more than one Tennant.
what have you tried so far to achieve this
Hi all,
I am trying to leverage the GitLab DevOps integration with our GL projects.
At the moment we have the following implementation:
GitLab Authentication for login into SQ (this is working fine)
DevOps Platform Integrations with GL for more than 1 ‘tenant’
As for the pt. 2 above since the 1st of January we have the following issues in SQ
Your GitLab token is expired - tenant_A
Your GitLab token has insufficient scope tenant_B
I want to focus on ‘tenant_B’ at the moment.
Let me explain,
We have created a Token in GL following the official GL and SQ guides.
We added this token to SQ configuration under Administration > Configuration > General Settings > DevOps > GitLab; since we did that, there was a green check mark showing us, that all is OK with this integration, however…
We have a dedicated teams and groups created in GL so GL_Team1 can’t see or access GL_Team2 code.
With the above implementation of DevOps tokens users from GL_T1 can see code from GL_T2 and vice versa! (this is when you creating new project and selecting portfolio, there is a option to ‘view source code’)
When we tried to poke around with this token and its premmisions we now have an error as reported at the beginning of the post.
My question is, how can we tackle this issue? How to create good working integration and how to separate GL_T1 from GL_T2.
Is there anything specific that needs to be do SQ Groups for example?
What is the best practice here of creating Tokens to scan projects?
Do we have to have for example a Group in SQ and create a token per project? (as I was told Personal tokens should not be used in case if a person leave the company, all tokens for this team need to be regenerated etc.)
I have full access to SQ instance and Administration rights.
I have limited access to GL and no Administration rights - therefore I have to trust our admins, that the followed the correct steps in creating the Token.
I’m having a hard time following all the content you’ve laid out – let me try my best.
There’s no particular reason that users from GL_T1 should be able to see projects from GL_T2. When you provision projects in SonarQube, you are asked to provide a token that is specific to the user provisioning projects.
This makes sure that a user can only see the projects that they have access to on Gitlab, and no other projects (even if the global token in your SonarQube administration configuration has that wider access).
Once projects are analyzed by SonarQube, project permissions determine what users can see about projects (their existence, their source code, etc.)
In SonarQube v9.9 you can use permission templates to define which groups should be allowed to see which project, and even automate this by providing a project key pattern to match (if there’s something distinct about each project key generated that defines whether it belongs to tenant A or tenant B).
In SonarQube v10.5 (not the next release, but the one after), we expect to go further and completely delegate project permissions to Gitlab so that you aren’t left managing permission templates, groups, users and individual permissions.
On the slightly separate topic of tokens used for scanning – when possible, we suggest using local SonarQube users (or technichal users that can login to your GitLab instance) and grant them Execute Analysis permissions. You can have project-specific or global analysis tokens, as documented here.
Hi Colin, thank you for a comprehensive answer.
We did some additional testing around users in GL and SQ an how the tokens are generated. This is our observation.
The access tokens (AT) can be created in GitLab (GL) in at least two spaces: 1 - user token ; 2 - group token!
So, let’s presume now that among 30 users we have in GL 4 have more access (ie. admin - can see all projects) and test have GL access as maintainer, developer etc.
We observed that once the GL user with more privileges generates the personal access token (1) he/she can view all projects in GL and once this token is used in SQ then all the projects are visible in SQ import list.
When the same user generate the group access token he/she can only see the protest in that GL group.
Now, considering that we ‘may have’ quite a mess in GL groups and permissions (that need to be reviewed later), you can image this lead to some problems like “I can see your projects in SQ - when importing - but not in GL”
quite a mess in GL groups and permissions (that need to be reviewed later), you can image this lead to some problems like “I can see your projects in SQ - when importing - but not in GL”