Authorize x-scan in CI/CD pipeline
I'm trying to summarize in this issue(So that you won't need to follow into other links in the issue, but feel free to do so if you need additional context):
- the question we are facing
- the progress so far
- candidate solutions
Related to previous issues: https://gitlab.com/gitlab-org/gitlab/-/issues/450828#note_1896617577 which has two sub issues:
-
Issue: XRay Add-On Access Issue in Subgroups Due to Na... (#456448 - closed)
-
merged MR: Check ancestor for current namespace (!150065 - merged)
-
Issue: Inconsistent Authorization for XRay Compared to... (#456449 - closed)
-
closed MR: Check all users in the group hierarch (!150560 - closed)
We will pick a solution before moving forward.
Progress so far
We've unblocked the sales team and they can now demo the xscan to our customers (details here https://gitlab.slack.com/archives/C072BJD6G5R/p1715093838201789, related MR Check ancestor for current namespace (!150065 - merged))
Closed MR: Check all users in the group hierarch (!150560 - closed) Because according to @derekferguson and @mikolaj_wawrzyniak , we should "step back from the Premium/Ultimate conversation until we know what the future of the feature looks like".
And the current authorization rule is: If there's a duo_pro_purchase for current namespace or parent namespaces, we allow the api call. This unblocked the sales team, but it won't cover the following usecase: user1 has seat in a active duo_pro_purchase, but the current project's namespace as well as it's parent_namespaces do not have duo_pro_purchase, and then the CI job triggered by user1 won't be allowed to access the scan API.
As discussed with tenant-scale team in MR !150560 (comment 1890437170), the approach described here #456449 (comment 1865050251) is not ideal(copied here to avoid page jump):
1. Request Initiated: When an XRay scan is requested, the API triggers a verification process.
2. Verification Query: The system executes a query to check all members of the project who have developer-level access or higher.
3. Check Add-On Seats: For each of these members, the system checks if they possess an Add-On seat in any group within GitLab.
4. Authorization: If any such member is found, the XRay scan is authorized for the project, regardless of the specific group hierarchy or the direct assignment of the Add-On seat to the project or its direct parent group.
the question we are facing
@mikolaj_wawrzyniak Gave a accurate scoping: Design authorisation mechanism for AI features triggered by non AI users for a benefit to AI users.
To expand on that: The xscan CICD job is calling /x_ray/scan api in rails. How can we auth the request?
- The request has the following relevant information
- the
job
- the job's
user
- the job's
namespace
- the
- /x_ray/scan api in rails is gated by duo_pro
add_on_purchase
- add_on_purchase has a namespace (we unblock sales by checking weather the job's namespace and parent namespaces have add_on, more in Progress so far above), note that add_on_purchase has a namespace only on saas, but add_on_purchase does not have a namepsace in dedicated instance
- add_on_purchase have many users(seats), which means add_on_purchase should have unlocked these users to access xray
Update 20240604: Rephrase the question: Is this group/project allowed to utilize xscan , IMO, there are two categories of AI-feature requests:
- User request(eg, code suggestions).
- Calculating the context (eg, RAG related, getting the organization-specific knowledge).
To auth requests in the first category is straight-forward, if the user has a seat in duo pro purchase, then we allow the request.
To auth requests in the second category is tricky, because a duo pro purchase does not have seat for a project or group. But usually a context is for a scope of project or group.
candidate solutions
current solution: mentioned above(repeat here): If there's a duo_pro_purchase for current namespace or parent name_spaces, we allow the api call.
Limitations: This unblocked the sales team, but it won't cover the following usecase: user1 has seat in a active duo_pro_purchase, but the current project's namespace as well as it's parent_namespaces do not have duo_pro_purchase, and then the CI job triggered by user1 won't be allowed to access the scan API.
candidate 1: only check the user, eg, if the user who triggers the CI Job has a seat in a active duo_pro purchase, we allow the job to call /x_ray/scan api in rails
Limitations: Imagine 10 users in a project, only one of them has a seat. This means 9 out of 10 users in the repo won't be able to successfully run the job. And the job will periodically fail consequently.
candidate 2: described above(repeat here): As discussed with tenant-scale team in MR !150560 (comment 1890437170), the approach described here #456449 (comment 1865050251) is not ideal(copied here to avoid page jump):
1. Request Initiated: When an XRay scan is requested, the API triggers a verification process.
2. Verification Query: The system executes a query to check all members of the project who have developer-level access or higher.
3. Check Add-On Seats: For each of these members, the system checks if they possess an Add-On seat in any group within GitLab.
4. Authorization: If any such member is found, the XRay scan is authorized for the project, regardless of the specific group hierarchy or the direct assignment of the Add-On seat to the project or its direct parent group.
Limitations:
- check each project members in all groups is too expensive, adding workload on psql server, adding cost to users' CI minutes cost.
- open to exploit/abuse, eg, invite a user to the project and then all jobs enjoy the xscan offering
candidate 3: For now for a add_on purchase, we only allocate seat to users. We can allocate seat to projects in this case.
Limitations:
- sizeable changes, may out of scope of code_creation. More related to tenant_scope team, IMO.
candidate 4: As mentioned by @mikolaj_wawrzyniak: Add some sort of project/group settings option where user with at least maintainer role could enable AI features for given project/group.
To mitigate exploit/abuse,We can track the identity of the user who enabled this setting for a given group and synchronize setting state with that user Add-On availability. (only maintainer with add-on seat in duo pro purchase can enable the setting)