Invalid and inconsistent behavior of CI_JOB_TOKEN when git access set to SSH ONLY and project visibility changes
We've found an invalid and inconsistent behavior of GitLab in context of enforcing Git protocol to Only SSH
when $CI_JOB_TOKEN
is the actor.
For context and in short:
-
GitLab Instance admins and/or group owners can decide which Git protocols should be available: both, only HTTP(s) or only SSH.
Admin level configuration is described at https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#configure-enabled-git-access-protocols.
Group level configuration is described at https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-git-access-protocols (BTW, it lacks the important warning we have in the admin section!)
-
When
only HTTP(s)
is set, users can clone git repositories only using thegit+https
protocol. Access withgit+ssh
will be disabled. -
When
only SSH
is set, users can clone git repositories only using thegit+ssh
protocol. Access withgit+https
will be disabled... except of a specific case.GitLab CI/CD jobs execution depends on
git+https
access. That's the only way how we can manage secure, automatic and short-living access to repositories from jobs.Recent discussion about why that's needed, linking also to past discussions and decision points can be found at !142487 (comment 1749894090).
So, the expected behavior is that if instance admin or group owner had enforced Enabled Git access protocols: Only SSH
, git+https
clones made with the ci-job-token:$CI_JOB_TOKEN
username and password - when the linked job is in a running
state - will still work. That's documented in the admin level configuration docs and should be also documented on the group level configuration docs.
However, one of our users found recently that this still doesn't work in their case. At the moment when Only SSH
is set, jobs start failing.
While debugging that, I was able to reproduce this only in one case - when project visibility level is set to PUBLIC. A job executed at that moment have indeed failed
But once I've changed the visibility level to PRIVATE, it succeeded as it's expected!
GitLab.com doesn't allow INTERNAL level to be set, so I couldn't check what's the behavior in this case.
Anyway, the behavior I've described above is inconsistent and just wrong!
First, we expect that $CI_JOB_TOKEN
authenticated request for a running job, will be able to use git+https
even if Only SSH
is chosen.
Second, such behavior change based on project visibility level is totally unintuitive and confusing: user expects the Enabled Git access protocols
to control this behavior (with the exceptions written in the documentation) and not other, unrelated settings.
What should we do:
-
Find out why project visibility changes behavior of allowing
git+https
access for$CI_JOB_TOKEN
even whenEnabled Git access protocols: Only SSH
is set. Once found - fix it, so that$CI_JOB_TOKEN
is accepted in all cases. -
Copy the warning we have at https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#configure-enabled-git-access-protocols to https://docs.gitlab.com/ee/user/group/access_and_permissions.html#restrict-git-access-protocols, so that group owners are also aware of this special exception and why it exists.