doc-locale/fr-fr/ci/jobs/ci_job_token.md
{{< details >}}
{{< /details >}}
Lorsqu'un job de pipeline CI/CD est sur le point de s'exécuter, GitLab génère un jeton unique et le met à disposition du job en tant que CI_JOB_TOKEN variable prédéfinie. Le jeton n'est valide que pendant l'exécution du job. Une fois le job terminé, l'accès au jeton est révoqué et vous ne pouvez plus utiliser le jeton.
Utilisez un jeton de job CI/CD pour vous authentifier auprès de certaines fonctionnalités GitLab à partir des jobs en cours d'exécution. Le jeton reçoit le même niveau d'accès que l'utilisateur qui a déclenché le pipeline, mais dispose d'un accès à moins de ressources qu'un jeton d'accès personnel. Un utilisateur peut déclencher un job en poussant un commit, en exécutant un job manuel ou en étant propriétaire d'un pipeline planifié. Cet utilisateur doit avoir un rôle disposant des privilèges requis pour accéder aux ressources.
Vous pouvez utiliser un jeton de job pour vous authentifier auprès de GitLab afin d'accéder aux ressources d'un autre groupe ou projet (le projet cible). Par défaut, le groupe ou le projet du jeton de job doit être ajouté à la liste des jetons de job autorisés du projet cible.
Si un projet est public ou interne, vous pouvez accéder à certaines fonctionnalités sans figurer sur la liste des autorisations. Par exemple, vous pouvez récupérer des artefacts de job à partir des pipelines publics du projet. Cet accès peut également être restreint.
{{< history >}}
{{< /history >}}
Les jetons de job CI/CD peuvent accéder aux ressources suivantes :
| Ressource | Notes |
|---|---|
| API Branches | Peut accéder au point de terminaison GET /projects/:id/repository/branches. |
| API Commits | Peut accéder aux points de terminaison GET /projects/:id/repository/commits/:sha et GET /projects/:id/repository/commits/:sha/merge_requests. |
| Registre de conteneurs | Utilisé comme variable prédéfinie $CI_REGISTRY_PASSWORD pour s'authentifier auprès du registre de conteneurs associé au projet du job. |
| Registre de paquets | Utilisé pour s'authentifier auprès du registre. |
| Registre de modules Terraform | Utilisé pour s'authentifier auprès du registre. |
| Fichiers sécurisés | Utilisé par la commande glab securefile pour utiliser des fichiers sécurisés dans les jobs. |
| API du registre de conteneurs | Peut s'authentifier uniquement auprès du registre de conteneurs associé au projet du job. |
| API Déploiements | Peut accéder à tous les points de terminaison de cette API. |
| API Environnements | Peut accéder à tous les points de terminaison de cette API. |
| API Fichiers | Peut accéder au point de terminaison GET /projects/:id/repository/files/:file_path/raw. |
| API Jobs | Peut accéder uniquement au point de terminaison GET /job. |
| API Artefacts de job | Peut accéder uniquement aux points de terminaison de téléchargement. |
| API Merge requests | Peut accéder aux points de terminaison GET /projects/:id/merge_requests et GET /projects/:id/merge_requests/:merge_request_iid. |
| API Notes | Peut accéder aux points de terminaison GET /projects/:id/merge_requests/:merge_request_iid/notes et GET /projects/:id/merge_requests/:merge_request_iid/notes/:note_id. |
| API Paquets | Peut accéder à tous les points de terminaison de cette API. |
| API Jetons de déclenchement de pipeline | Peut accéder uniquement au point de terminaison POST /projects/:id/trigger/pipeline. |
| API Pipelines | Peut accéder uniquement au point de terminaison PUT /projects/:id/pipelines/:pipeline_id/metadata. |
| API Liens de release | Peut accéder à tous les points de terminaison de cette API. |
| API Releases | Peut accéder à tous les points de terminaison de cette API. |
| API Dépôts | Peut accéder uniquement au point de terminaison GET /projects/:id/repository/changelog des dépôts publics. |
| API Tags | Peut accéder aux points de terminaison GET /projects/:id/repository/tags et GET /projects/:id/repository/tags/:tag_name. |
Une proposition ouverte existe pour rendre les permissions plus granulaires.
Si un jeton de job est compromis, il pourrait potentiellement être utilisé pour accéder aux données privées accessibles à l'utilisateur qui a exécuté le job CI/CD. Pour aider à prévenir la fuite ou l'utilisation abusive de ce jeton, GitLab :
Vous devez également configurer vos runners pour qu'ils soient sécurisés :
privileged si les machines sont réutilisées.shell lorsque les jobs s'exécutent sur la même machine.Une configuration GitLab Runner non sécurisée augmente le risque que quelqu'un puisse voler des jetons d'autres jobs.
Vous pouvez contrôler quels groupes ou projets peuvent utiliser un jeton de job pour s'authentifier et accéder à certaines ressources de votre projet.
Par défaut, l'accès au jeton de job est limité aux seuls jobs CI/CD qui s'exécutent dans les pipelines de votre projet. Pour permettre à un autre groupe ou projet de s'authentifier avec un jeton de job provenant du pipeline de l'autre projet :
Si votre projet est public ou interne, certaines ressources accessibles publiquement peuvent être accédées avec un jeton de job depuis n'importe quel projet. Ces ressources peuvent également être limitées aux seuls projets figurant sur la liste des autorisations.
Les administrateurs de GitLab Self-Managed peuvent remplacer et appliquer ce paramètre. Lorsque le paramètre est appliqué, le jeton de job CI/CD est toujours limité à la liste des autorisations du projet.
{{< history >}}
:inbound_ci_scoped_job_token, activé par défaut.{{< /history >}}
Vous pouvez ajouter des groupes ou des projets à votre liste des jetons de job autorisés pour permettre l'accès aux ressources de votre projet avec un jeton de job pour l'authentification. Par défaut, la liste des autorisations de tout projet ne comprend que lui-même. N'ajoutez des groupes ou des projets à la liste des autorisations que lorsqu'un accès inter-projets est nécessaire.
L'ajout d'un projet à la liste des autorisations ne confère pas de permissions supplémentaires aux membres du projet autorisé. Ils doivent déjà disposer des permissions nécessaires pour accéder aux ressources de votre projet afin d'utiliser un jeton de job du projet autorisé pour accéder à votre projet.
Par exemple, le projet A peut ajouter le projet B à la liste des autorisations du projet A. Les jobs CI/CD du projet B (le « projet autorisé ») peuvent désormais utiliser des jetons de job CI/CD pour authentifier les appels d'API REST afin d'accéder au projet A.
Prérequis :
Pour ajouter un groupe ou un projet à la liste des autorisations :
Vous pouvez également ajouter un groupe ou un projet à la liste des autorisations via l'API.
{{< history >}}
{{< /history >}}
Les projets ne figurant pas sur la liste des autorisations peuvent utiliser un jeton de job pour s'authentifier auprès de projets publics ou internes afin de :
Vous pouvez limiter l'accès à ces actions aux seuls projets figurant sur la liste des autorisations en configurant chaque fonctionnalité pour qu'elle ne soit visible que par les membres du projet.
Prérequis :
Pour configurer une fonctionnalité afin qu'elle ne soit visible que par les membres du projet :
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
[!warning] Désactiver la limite d'accès au jeton et la liste des autorisations constitue un risque de sécurité. Un utilisateur malveillant pourrait tenter de compromettre un pipeline créé dans un projet non autorisé. Si le pipeline a été créé par l'un de vos maintainers, le jeton de job pourrait être utilisé pour tenter d'accéder à votre projet.
Si vous désactivez la liste des jetons de job CI/CD autorisés, les jobs de n'importe quel projet peuvent accéder à votre projet avec un jeton de job. L'utilisateur qui déclenche le pipeline doit avoir la permission d'accéder à votre projet. Vous ne devez désactiver ce paramètre qu'à des fins de test ou pour une raison similaire, et vous devez le réactiver dès que possible.
Cette option n'est disponible que sur les instances GitLab Self-Managed ou GitLab Dedicated avec le paramètre Enable and enforce job token allowlist for all projects désactivé.
Prérequis :
Pour désactiver la liste des jetons de job autorisés :
Vous pouvez également modifier ce paramètre avec l'API GraphQL (inboundJobTokenScopeEnabled) ou l'API REST.
{{< history >}}
allow_push_repository_for_job_token. Désactivé par défaut.allow_push_repository_for_job_token supprimé.{{< /history >}}
Vous pouvez configurer votre projet pour autoriser les requêtes de poussée Git authentifiées avec un jeton de job CI/CD. Ce paramètre est désactivé par défaut.
Lorsque vous activez ce paramètre, seuls les jetons de job générés par des jobs CI/CD s'exécutant dans les pipelines du projet peuvent pousser vers le projet.
Lorsque vous utilisez un jeton de job pour pousser vers le projet, aucun pipeline CI/CD n'est déclenché. Le jeton de job dispose des mêmes permissions d'accès que l'utilisateur qui a démarré le job.
Si vous utilisez l'outil semantic-release, ce paramètre pourrait empêcher la création de pipelines.
[!warning] N'activez pas ce paramètre sur les projets configurés comme miroirs de tirage, en particulier si des pipelines s'exécutent pour les mises à jour du miroir. Le propriétaire du dépôt en amont pourrait tenter d'utiliser
CI_JOB_TOKENpour pousser des commits vers le projet mis en miroir.
Prérequis :
Pour accorder la permission aux jetons de job générés dans votre projet de pousser vers le dépôt du projet :
Vous pouvez également contrôler ce paramètre avec le paramètre ci_push_repository_for_job_token_allowed dans l'API projets.
{{< history >}}
allow_push_to_allowlisted_projects. Désactivé par défaut.{{< /history >}}
[!flag] La disponibilité de cette fonctionnalité est contrôlée par un feature flag. Pour plus d'informations, consultez l'historique.
Vous pouvez autoriser les jetons de job CI/CD des projets autorisés à pousser vers le dépôt de votre projet. Ceci est utile pour les workflows GitOps, le balisage de sous-modules et les pipelines CI/CD inter-dépôts sans jetons d'accès de longue durée.
Lorsqu'une poussée par jeton de job réussit, aucun pipeline CI/CD n'est déclenché dans le projet cible.
[!warning] N'activez pas ce paramètre sur les projets configurés comme miroirs de tirage, en particulier si des pipelines sont déclenchés pour les mises à jour du miroir. Un propriétaire d'un projet source autorisé pourrait pousser des commits vers votre projet mis en miroir en utilisant un jeton de job CI/CD.
Pour que la poussée inter-projets fonctionne, toutes les conditions suivantes doivent être remplies :
admin_repositories, ou avec les permissions par défaut (aucune restriction fine-grained définie). Une entrée de groupe sur la liste des autorisations qui inclut le projet source satisfait également à cette exigence.Prérequis :
Pour autoriser les requêtes de poussée inter-projets :
ADMIN_REPOSITORIES, ou laissez les permissions par défaut activées.Vous pouvez utiliser les permissions fine-grained pour autoriser explicitement l'accès à un ensemble limité de points de terminaison de l'API REST.
Pour plus d'informations, consultez les permissions fine-grained pour les jetons de job CI/CD.
Vous pouvez utiliser le jeton de job pour vous authentifier et cloner un dépôt depuis un projet privé dans un job CI/CD. Utilisez gitlab-ci-token comme utilisateur et la valeur du jeton de job comme mot de passe.
Par exemple :
git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/<namespace>/<project>
Vous pouvez utiliser ce jeton de job pour cloner un dépôt même si le protocole HTTPS est désactivé par les paramètres du groupe, du projet ou de l'instance.
Vous pouvez utiliser un jeton de job pour authentifier des requêtes vers des points de terminaison spécifiques de l'API REST en utilisant ces méthodes :
--header "JOB-TOKEN: $CI_JOB_TOKEN" (recommandé)--form "token=$CI_JOB_TOKEN"--data "job_token=$CI_JOB_TOKEN"?job_token=$CI_JOB_TOKEN (non recommandé)Par exemple, en utilisant la méthode d'en-tête recommandée :
curl --verbose --request POST --header "JOB-TOKEN: $CI_JOB_TOKEN" --form ref=master "https://gitlab.com/api/v4/projects/1234/trigger/pipeline"
Pour des conseils sur la sécurité des jetons, consultez les considérations de sécurité.
Vous ne pouvez pas utiliser de jetons de job pour authentifier des requêtes GraphQL.
{{< history >}}
{{< /history >}}
Vous pouvez suivre quels autres projets utilisent un jeton de job CI/CD pour s'authentifier auprès de votre projet dans un journal d'authentification. Pour consulter le journal :
Le journal d'authentification affiche un maximum de 100 événements d'authentification. Si le nombre d'événements est supérieur à 100, téléchargez le fichier CSV pour consulter le journal.
Les nouvelles authentifications auprès d'un projet peuvent prendre jusqu'à 5 minutes pour apparaître dans le journal d'authentification.
{{< history >}}
{{< /history >}}
À partir de GitLab 19.0, les jetons de job CI/CD utilisent le standard JWT par défaut. Les projets peuvent continuer à utiliser le format hérité en configurant le groupe principal de leur projet. Ce paramètre n'est disponible que jusqu'à la release de GitLab 20.0.
Pour utiliser le format hérité pour vos jetons CI/CD :
Vos jetons CI/CD utilisent désormais le format hérité. Si vous souhaitez utiliser à nouveau le format JWT ultérieurement, vous pouvez réactiver ce paramètre.
Les échecs de jeton de job CI sont généralement affichés sous la forme de réponses comme 404 Not Found ou similaires :
Clone Git non autorisé :
$ git clone https://gitlab-ci-token:[email protected]/fabiopitino/test2.git
Cloning into 'test2'...
remote: The project you were looking for could not be found or you don't have permission to view it.
fatal: repository 'https://gitlab-ci-token:[MASKED]@gitlab.com/<namespace>/<project>.git/' not found
Téléchargement de paquet non autorisé :
$ wget --header="JOB-TOKEN: $CI_JOB_TOKEN" ${CI_API_V4_URL}/projects/1234/packages/generic/my_package/0.0.1/file.txt
--2021-09-23 11:00:13-- https://gitlab.com/api/v4/projects/1234/packages/generic/my_package/0.0.1/file.txt
Resolving gitlab.com (gitlab.com)... 172.65.251.78, 2606:4700:90:0:f22e:fbec:5bed:a9b9
Connecting to gitlab.com (gitlab.com)|172.65.251.78|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-09-23 11:00:13 ERROR 404: Not Found.
Requête d'API non autorisée :
$ curl --verbose --request POST --form "token=$CI_JOB_TOKEN" --form ref=master "https://gitlab.com/api/v4/projects/1234/trigger/pipeline"
< HTTP/2 404
< date: Thu, 23 Sep 2021 11:00:12 GMT
{"message":"404 Not Found"}
< content-type: application/json
Lors du dépannage des problèmes d'authentification par jeton de job CI/CD, soyez conscient que :
semantic-release et les jetons de job {#the-semantic-release-tool-and-job-tokens}Il existe un problème connu si vous utilisez l'outil semantic-release avec le paramètre Autoriser les requêtes de poussée Git dans le dépôt. Lorsqu'il est activé :
Pour plus d'informations, consultez le ticket 891.
Il existe des problèmes connus avec le format JWT pour les jetons de job CI/CD.
Error when persisting the task ARN. avec l'exécuteur personnalisé EC2 Fargate Runner {#error-when-persisting-the-task-arn-error-with-ec2-fargate-runner-custom-executor}Il existe un bug dans la version 0.5.0 et les versions antérieures de l'exécuteur personnalisé EC2 Fargate. Ce problème provoque cette erreur :
Error when persisting the task ARN. Will stop the task for cleanupPour résoudre ce problème, mettez à niveau vers la version 0.5.1 ou une version ultérieure de l'exécuteur personnalisé Fargate.
invalid character '\n' in string literal avec l'encodage base64 {#invalid-character-n-in-string-literal-error-with-base64-encoding}Si vous utilisez base64 pour encoder des jetons de job, vous pourriez recevoir une erreur invalid character '\n'.
Le comportement par défaut de la commande base64 enveloppe les chaînes de caractères de plus de 79 caractères. Lors de l'encodage base64 des jetons de job au format JWT pendant l'exécution du job, par exemple avec echo $CI_JOB_TOKEN | base64, le jeton est rendu invalide.
Pour résoudre ce problème, utilisez base64 -w0 pour désactiver l'enveloppement automatique du jeton.
403 Forbidden dans les jobs de longue durée {#error-403-forbidden-in-long-running-jobs}Lors de l'utilisation de jetons de job au format JWT dans GitLab 18.8 et versions antérieures, un job pourrait échouer avec une erreur 403 Forbidden. Cela peut se produire dans :
needs.L'erreur apparaissait généralement dans les logs du runner sous la forme :
WARNING: Submitting job to coordinator... job failed
code=403 job=<job_id> status=PUT https://gitlab.com/api/v4/jobs/<job_id>: 403 Forbidden
Mettez à niveau vers GitLab 18.9 pour éviter ce problème.