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

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 ! Je commençais à devenir fou !

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:

contrôle d'accès du CI_JOB_TOKEN de mon projet ayant le conteneur poetry contrôle d'accès du CI_JOB_TOKEN de mon projet ayant le conteneur poetry

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.

Paramètres de contrôle d'accès du CI_JOB_TOKEN de mon projet de conteneur poetry Paramètres de contrôle d'accès du CI_JOB_TOKEN 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 ! J'adore quand un plan se déroule sans accroc !

Historique des changements

Activé par défaut depuis la v15.9 Activé par défaut depuis la v15.9

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.

Liens