Mise à jour de Gitlab C.E et contrôle d'accès du CI_JOB_TOKEN
Changement de comportement dans le contrôle d’accès du CI_JOB_TOKEN lors d’une mise à jour d’instance Gitlab Community Edition
Table des matières
![](images/thumbnail.webp)
Introduction générale 📚
Au CC-IN2P3, nous hébergeons notre propre instance de Gitlab Community Edition. Notre instance a récemment été mise à jour vers la version la plus récente de Gitlab.
Je suis habitué à créer un grand nombre de conteneurs spécialisés que j’utilise dans mon travail quotidien avec la C.I Gitlab.
Le dernier conteneur que j’ai eu à créer est un conteneur fournissant python poetry. Cela dans le but de l’utiliser pour contruire et déployer mes projets Python. Je ne suis vraiment pas un grand fan de Python 🐍 mais … un grand nombre de personnes l’utilisent dans mon travail. Je dois donc faire avec 🤷. Mais quand même, les type hints de Python sont vraiment une blague… 🤯.
Comment j’ai découvert qu’un comportement avait changé ?
Etape 1 - Créer un nouveau projet et l’image du conteneur
Comme à mon habitude, j’ai créé un nouveau projet dans notre instance Gitlab. Le projet a été créé après que notre instance ait été mise à jour.
Comme d’habitude, mon C.I / C.D a automatiquement créé des images de conteneurs telles que:
gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9:1
gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9:1.5
gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9:1.5.1
Si vous ne connaissez pas rockylinux
, c’est une distribution Linux basée sur RedHat.
Avec almalinux
, c’est l’une des deux principales distributions qui sont apparues après l’annonce de la fin de vie du projet CentOS.
Etape 2 - Utiliser l’image du conteneur dans un job C.I
Dans un autre projet Python, je cherchais à utiliser l’image gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9:1.5
afin de construire et déployer mon application.
Voici un exemple de fichier .gitlab-ci.yml
que j’ai utilisé:
---
stages:
- "build"
build-app:
stage: "build"
image: "gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9:1.5"
script:
- "poetry build"
- "poetry install"
Rien de bien nouveau. Je suis habitué à faire ce genre de choses. Il n’y a aucune raison que quoi que ce soit échoue, je peux aller prendre mon café ☕ … enfin ça c’est ce que je croyais !
Etape 3 - L’erreur incompréhensible dans mon job C.I
Voici l’erreur qui est apparue dans mon job C.I:
Running with gitlab-runner 15.x.y (436155cb)
on runner@gitlab.example.org 98238a4c, system ID: x_fdsfkdsf89
Preparing the "docker" executor 00:04
Using Docker executor with image gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9:1.5 ...
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9:1.5 ...
WARNING: Failed to pull image with policy "always": Error response from daemon: pull access denied for gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9, repository does not exist or may require 'docker login': denied: requested access to the resource is denied (manager.go:237:0s)
ERROR: Job failed: failed to pull image "gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9:1.5" with specified policies [always]: Error response from daemon: pull access denied for gitlab-registry.example.org/containers/poetry/python3.11/rockylinux9, repository does not exist or may require 'docker login': denied: requested access to the resource is denied (manager.go:237:0s)
La seule ligne vraiment pertinente est:
failed to pull image [...]: Error response from daemon: pull access denied
Etape 4 - Mais pourquuooii ?!
Après de nombreux essais, tous les nouveaux projets que je créais était incapable d’utiliser l’image poetry
du conteneur que j’avais construit. Tous les jobs C.I échouaient avec l’erreur pull access denied
vue précédemment.
J’étais en revanche capable d’utiliser d’autres images de conteneurs, de précédents projets pourtant dans le même namespace.
![Je commençais à devenir fou !](images/rough-day-keyboard.gif)
J’ai dû créer environ 10 nouveaux projets gitlab pour essayer, taguer, pousser de nouvelles images et faire des tentatives. Et j’obtenais systématiquement la même erreur pull access denied
lorsque j’utilisais une image de conteneur provenant d’un projet nouvellement créé.
Mais que se passe t’il ? Mais qu’est-ce qui se passe ?
Comment fonctionne le CI_JOB_TOKEN
?
Lorsqu’un job C.I s’exécute, il s’authentifie automatiquement auprès de la registry Gitlab via le CI_JOB_TOKEN
généré pour le job.
Ce token hérite des permissions de l’utilisateur ayant soumis le pipeline.
Découverte d’un paramètre étant récemment passé actif par défaut
En me promenant dans les paramètres de mon projet de conteneur poetry
sous le menu Settings
-> C.I / C.D
, j’ai découvert une section intéressante:
Le menu décrit qu’il “Control how the CI_JOB_TOKEN CI/CD variable is used for API access between projects”. Traduction: Contrôle la façon dont la variable CI_JOB_TOKEN des jobs C.I peut-être utilisée pour les accès API entre les projets. Et l’option Allow access to this project with a CI_JOB_TOKEN
est activée. Il y a en dessous une liste explicite permettant de gérer une list blanche des projets pouvants accéder à mon conteneur poetry
via leur CI_JOB_TOKEN
.
Solution rapide
En regardant l’historique des versions de Gitlab, j’ai découvert que l’option Allow access to this project with a CI_JOB_TOKEN
avec sa list blanche avait été activée par défaut pour les nouveaux projets dans les dernières versions de Gitlab Community Edition.
Une solution rapide a été de rajouter mon application python dans la list blanche des Token Access
de mon projet de conteneur poetry
.
Une fois l’ajout à la liste blanche effectué, je n’ai eu qu’à relancer mes pipelines et attendre 👀…
![J'adore quand un plan se déroule sans accroc !](images/epic_win.png)
Historique des changements
Il semblerait que cette option soit activée par défaut pour les nouveaux projets depuis Gitlab v15.9
.
Il semblerait également qu’il soit d’ores et déjà possible d’automatiser cette mise en liste blanche via les APIs Gitlab.
Soyez le premier à commenter! 🥇