Add inbound access control for job token
What does this MR do and why?
This adds the inbound access control as part of:
Technical notes
This shouldn't cause any changes for users when released. Since the flag is disabled and the feature is disabled by default for each project and cannot be updated since it's behind a feature flag.
How we add project's
We always add a project to the inbound scope's allowlist by specifying the project we are targeting for the allowlist or target project !99166 (merged).
How we check inbound access
For projects in displayed on the inbound allowlist for a given project. We want to enforce the added project can access the project it was added to. This means when checking if a current_project is allowed to access another project we can't simply check the inbound allowlist on the current project. Instead we need to check in the inverse direction for :inbound direction links - i.e. which links exist where the current_project is the target_project and the source_project is the accessed_project.
Finally, if both inbound and outbound scope settings are enabled the project will have to be configured properly on both sides for access to work.
Example
Say I want project A to access Project B and project A has inbound scope enabled and outbound scope enabled.
That would mean I need to navigate to project A and add project B to the outbound allowlist and then navigate to project B and add project A to it's inbound allowlist.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.