Restricting job token for public and internal projects

What does this MR do and why?

Moved from security to canonical, as it is a special case

The initial review went on security MR

Summary issue: https://gitlab.com/gitlab-org/gitlab/-/issues/425322

See #405369 (comment 1463412587) for the specific details. The main idea is

• For public/internal projects that have ci_job_token_inbound_scope enabled. Access to their container/packages/releases/artifacts will determine on the project's settings
• If the calling project is not in the allowlist of the target project
  • If it's "Everyone with Access"
    • Then there are no checks required
  • If it's "Only for project members"
    • Then the calling project needs to be on the target project's ci_job_inbound_scope allowlist
  • If it's "Disabled"
    • No access is given
• If the calling project is in the allowlist
  • There are no checks required
• This change only affects inbound, as outbound is deprecated and scoped out

Screenshots or screen recordings

Not much as it's mainly a permission change. But jobs will be begin failing with permission errors.

For Example: When the Job needs artifacts, but the public CI/CD Setting is set to Project Members Only

++ echo 'Downloading artifacts for job1 (1081)...'
Downloading artifacts for job1 (1081)...
++ /usr/bin/gitlab-runner-helper artifacts-downloader --url http://172.16.123.1:3000/ --token [MASKED] --id 1081
ERROR: Downloading artifacts from coordinator... forbidden  host=172.16.123.1:3000 id=1081 responseStatus=403 Forbidden status=GET http://172.16.123.1:3000/api/v4/jobs/1081/artifacts: 403 Forbidden token=64_a5599
FATAL: permission denied                           
ERROR: Job failed: exit code 1

For Example: When the job needs to pull from a container registry, but the public project's registry is set to Project Members Only

$ docker pull registry.test:5000/root/environments:latest
Error response from daemon: pull access denied for registry.test:5000/root/environments, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
ERROR: Job failed: exit code 1

How to set up and validate locally

1. (To test Artifacts) Have an upstream project with gitlab-ci.yml

   stages:
       - test
       - deploy
   
   job1:
       stage: test
       script: echo 'done' > output.txt
       artifacts:
           paths:
               - output.txt
   
   staging:
       stage: deploy
       trigger:
           project: 'root/downstreamproj'
           strategy: depend

2. Have a downstream project with gitlab-ci.yml

   downstream_job:
       stage: test
       needs:
           - project: 'root/upstreamproj'
             job: job1
             ref: main
             artifacts: true
       script: 
         - cat output.txt

To Test Container Registry:

Have the job pulling the container registry have gitlab-ci.yaml (Note, this will depend on your docker set-up (if you are using docker), how the registry is enabled and where it is at)

image: docker:stable

services:
  - name: docker:stable-dind
    command: ["--insecure-registry=registry.test:5000"] # Only required if the registry is insecure

stages:
  - build

build:
  stage: build
  variables:
    DOCKER_TLS_CERTDIR: ""
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker pull registry.test:5000/root/environments:latest

In the example above, the docker is trying to pull from project environments.

Therefore in my project http://gdk.test:3000/root/Environments/container_registry I have created a container registry.

For the other permissions that this MR touched (eg. pipeline triggers, deployments) they're mostly testable through API calls. Therefore changing the project's permissions will return 403/404 (legacy reasons on the whole debate of unauthorized/notfound) in the api responses, where it previously returned 200.

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.