Allow job tokens to access internal packages
🌳 What does this MR do and why?
Packages should be accessible from internal projects if you are a logged in user. Currently, they are if you are using a personal access token, but CI_JOB_TOKENs fail.
The reason they fail is explained in this MR description where we fixed the same problem for public projects. The short version is the job token checks the :build_read_project
permission rather than the :read_project
permission.
So in this MR, we update the :build_read_project
permission to allow internal project access, which then also allows for internal package access.
📸 Screenshots or screen recordings
Installing a package from an internal project with a CI_JOB_TOKEN used by a user not a member of the internal project
Before change | After change |
---|---|
💻 How to set up and validate locally
To test, you will need to have gitlab-runner
working locally with your GDK or development setup.
- Create a project (I will call it the package project here) and set it's visibility to
internal
- Publish a package to the package project. I suggest an npm package by following the npm docs.
- Create a new user. It is important that this user is not a member of the package project.
- While logged in as the new user, create a separate project (I will call it the CI project here)
- In the CI project, add a
.gitlab-ci.yml
file to install the package. For npm, this can be:image: node:latest stages: - deploy deploy: stage: deploy script: - npm config set -- '//127.0.0.1:3000/api/v4/projects/26/packages/npm/:_authToken' "${CI_JOB_TOKEN}" - npm config set @foo:registry http://127.0.0.1:3000/api/v4/projects/26/packages/npm/ - npm install @foo/stuff
@foo/stuff
- Let the job run, it should be successful.
If you'd like to see the failure scenario, revert the line in the project_policy.rb
file. Rerunning the pipeline should result in a failure, where the npm install
command receives a 404.
🛃 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.
Related to #333444 (closed)