Les principaux types de tokens GitLab

📝 Contexte

GitLab est une plateforme d'hébergement de code source et de gestion de projet qui offre diverses fonctionnalités pour faciliter le travail collaboratif.

Pour utiliser certaines de ces fonctions, il faut créer des "tokens" qui permettent à l'API de GitLab d'accéder aux données sans avoir besoin de mot de passe.

Ce document décrit les principaux types de tokens qui existent pour GitLab.

👤 Personal Access Token (PAT)

Un jeton d'accès personnel est un jeton unique créé par un membre de la plateforme GitLab.

Ce type de token permet à son propriétaire d'accéder à toutes les fonctionnalités de la plateforme, y compris la gestion des projets et des intégrations.

Les PAT sont généralement utilisés pour l'administration de la plateforme ou la mise en place de scripts automatisés.

Le scope d'autorisations et une date d'expiration sont à définir pour ce type de tokens.
Si aucune date d’expiration n’est renseignée, elle est automatiquement définie à +365 jours de la date de création.

Par défaut, ce jeton hérite des droits de son créateur.

Ils peuvent être utilisés pour s'authentifier à :

• L'API GitLab

• Les projets GitLab

• La registry GitLab

🔗 https://docs.gitlab.com/user/profile/personal_access_tokens/

📍 Job Token

Un Job Token est un jeton temporaire créé pour une opération spécifique, comme la création d'une tâche CI/CD.

Chaque job généré par GitLab hérite d'un Job Token le temps de l'exécution. Ce type de token n'est valable que pour le temps du job pour lequel il a été créé et est révoqué automatiquement après son utilisation.

Il est accessible au travers de la variable ${CI_JOB_TOKEN}.

Par défaut, ce jeton hérite des droits de l'utilisateur ayant déclenché la pipeline mais possède certaines restrictions.

Il est possible d'étendre les droits d'un Job Token à d'autres projets en utilisant les allowlists.

Par exemple, un projet nommé A peut ajouter le projet B à sa allowlist. Les jobs CI/CD du projet B pourront désormais utiliser des Job Tokens pour authentifier les appels d'API afin d'accéder au projet A.

🔗 https://docs.gitlab.com/ci/jobs/ci_job_token/

📁 Project Access Token

Un Project Access Token est attribué à un projet spécifique et permet aux membres de ce projet d'accéder à certaines fonctionnalités, comme la gestion des tâches CI/CD ou l'utilisation des intégrations.

Ce type de token est lié à un projet en particulier et peut être utilisé pour des opérations qui nécessitent un accès limité à certaines données du projet lui-même.

Le scope d'autorisations et une date d'expiration sont à définir pour ce type de tokens.
Si aucune date d’expiration n’est renseignée, elle est automatiquement définie à +30 jours de la date de création.

GitLab créé automatiquement un utilisateur bot lorsqu'un Project Access Token est créé. Ce sont des comptes de service et ne sont pas comptabilisé dans les licences.

Ils peuvent être utilisés pour s'authentifier à :

• L'API GitLab

• Les projets GitLab

• La registry GitLab

🔗 https://docs.gitlab.com/user/project/settings/project_access_tokens/

🤝 Group Access Token

Un Group Access Token est attribué à un groupe spécifique et permet aux membres de ce groupe d'accéder à certaines fonctionnalités, comme la gestion des projets ou l'utilisation des intégrations.

Ce type de token est lié à un groupe en particulier et peut être utilisé pour des opérations qui nécessitent un accès limité à certaines données des projets faisant parti du groupe.

Le scope d'autorisations et une date d'expiration sont à définir pour ce type de tokens.
Si aucune date d’expiration n’est renseignée, elle est automatiquement définie à +365 jours de la date de création.

GitLab créé automatiquement un utilisateur bot lorsqu'un Group Access Token est créé. Ce sont des comptes de service et ne sont pas comptabilisé dans les licences.

Par défaut, un Group Access Token ne peut pas avoir accès à des projets en dehors du groupe GitLab sur lequel il a été créé.

Ils peuvent être utilisés pour s'authentifier à :

• L'API GitLab

• Les projets GitLab

• La registry GitLab

🔗 https://docs.gitlab.com/user/group/settings/group_access_tokens/

🏁 Conclusion

Il est déconseillé d'utiliser les PAT dans le cadre de jobs CI/CD du au fait de son large spectre d'autorisations.

Privilégier plutôt les autres types de tokens avec comme ordre de préférence les tokens ayant le moins de droits étendus possibles :

1. Job tokens

2. Project tokens

3. Group tokens

Faire attention que les droits s'appliquent bien dans le cadre de pipelines CI/CD qui dépendent de plusieurs projets / groupes.