Does "Allow access to this project with a CI_JOB_TOKEN" in GitLab work between private repositories?

I am part of a private group (our team in our department). All underlying projects and subgroups can only be private (this is how GitLab works) and we all have at least Report-level access to those. Not to be confused with the personal namespace for each user!

I have created a subgroup with multiple repositories inside for a large Django project I am working on. One of the repositories (main, also includes manage.py as well as the Django project main files that are used by django-admin to configure and run the whole project) is referencing a couple of the others as submodules (Django apps).

I am trying to create a building job using Kaniko that is configured in the main repo and uses both the repo's own code as well as all the submodules to make the application complete. Sadly, I am encountering an authentication problem.

Even though I am the owner of the subgroup as well as the repos inside, cloning a submodule apparently still requires username and password. My setup does not allow me to use git config to add the required credentials - an automatically generated CI user and CI_JOB_TOKEN - I decided to look into sharing these credentials among all repos that are in some way linked (main repo + submodules).

In the CI/CD section of the Web UI in GitLab I have the following option:

I tried to set the path to the project to my main repo that uses the current repo as a submodule. However, I am getting

The target_project that you are attempting to access does not exist or you don't have permission to perform this action

The project does exist (tried with and without the .git suffix) so the only thing that remains is, yet again a credentials issue.

I might have missed a hint but the official documentation doesn't say that private repos cannot share a token.

Check if GitLab 16.1 (June 2023) can help:

> ## CI/CD job token scope API endpoint
>
> Starting in GitLab 16.0, the default CI/CD job token (CI_JOB_TOKEN) scope changed for all new projects. This increased the security of new projects, but added an extra step for users who used automation to create projects. The automation sometimes has to configure the job token scope as well, which could only be done with GraphQL (or manually in the UI), not the REST API.
>
> To make this setting configurable through the REST API as well, Gerardo Navarro added a new endpoint to control the job token scope in 16.1. It is available to users with a Maintainer or higher role in the project. Thank you for this great contribution Gerardo!

See Documentation and Issue.

> Create an allowlist of projects which can access your project through their CI_JOB_TOKEN.
>
For example, project A can add project B to the allowlist.
CI/CD jobs in project B (the “allowed project”) can now use their CI/CD job token to authenticate API calls to access project A. If project A is public or internal, the project can be accessed by project B without adding it to the allowlist.
>
> By default, the allowlist of any project only includes itself.
>
> It is a security risk to disable this feature, so project maintainers or owners should keep this setting enabled at all times.
Add projects to the allowlist only when cross-project access is needed.

Currently I was unable to find any information on the sharing of CI job tokens between private repositories. However one way to deal with this is to put the private repositories in a private group and create a private token that works as a job token. I haven't tried naming such a token as gitlab-ci-token but it could work.

I can confirm that is possible to add the permission to a private project. The problem is the confusing gitlab UI that does not accept the entire URL of a repo and requires the user to inform just the final part.

I had a repo with the following url:

https://gitlab.com/mygroup/mysubgroup/myreponame

I was adding the entire url path to it, I was getting the same error:

The target_project that you are attempting to access does not exist or you don't have permission to perform this action

Then I realized that all I needed to do was add just the final part:

mygroup/mysubgroup/myreponame

And it worked.