Exempt public/internal projects from job token scope
What does this MR do?
Related to #336398 (closed)
Background
In #329550 (closed) we introduced a concept of CI Job Token Scope which is an allowlist of projects (populated by maintainers) that defines which projects are authorized via CI_JOB_TOKEN authentication.
This technique prevents stealing private job user's information if the CI_JOB_TOKEN is leaked. If the token scope feature is enabled via project settings, only the authorized projects are allowed to be accessed, still according to the user's permissions. This prevents a user's private project from being leaked unless it's added to the job token scope.
Problem
One problem we saw while deploying this feature was that it was too strict. Unless a project is allowlisted we prevent all access. This was problematic for public projects where CI_JOB_TOKEN is used to access public resources like downloading container images, packages, etc.
Solution
In this MR we are exempting public projects from having permissions enforced via CI Job Token Scope.
This MR also contains some changes that are reverts from !62733 (merged) in some specs to ensure that job token coming from other projects can still have access when job token scope is disabled (current default).
Project setting disabled
pulling a docker image from a Private project is always allowed as long as the user has access to it.
Project setting enabled
| Description | Screenshot |
|---|---|
| pull from Internal project not in scope |  |
| pull from Public project not in scope |  |
| pull from Private project not in scope |  |
| pull from Private project after being added to the scope |  |
Does this MR meet the acceptance criteria?
Changelog not added since the feature is still behind a disabled feature flag.
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Security
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team